Authentication looks simple until an application has multiple roles, protected APIs, administrative workflows, and sensitive business data. At that point, login is only one part of the problem. The application also needs to decide how sessions are stored, how requests are authenticated, and where authorization decisions belong.
Authentication is not authorization
Authentication answers who the user is. Authorization answers what that user is allowed to do. Keeping those responsibilities separate makes the application easier to reason about and reduces the chance of accidentally protecting a route without protecting the underlying operation.
Why HttpOnly cookies are useful
HttpOnly cookies allow session information to be sent with requests without exposing the cookie value directly to client-side JavaScript. This can reduce the impact of certain client-side attacks when combined with appropriate cookie, CSRF, validation, and session-management controls.
Protecting the real authorization boundary
Protecting a page in the UI is not enough. The API or server-side operation that changes sensitive data must enforce authorization independently. UI restrictions improve the user experience, while server-side authorization provides the actual security boundary.
The lesson from production systems
Authentication architecture becomes much easier to maintain when session validation, authorization rules, password verification, and route protection have clear responsibilities instead of being scattered throughout the application.
