Authentication and Authorization Patterns

Building a secure web application is impossible without robust systems to verify who a user is and what they are allowed to do. While often mentioned together, authentication and authorization are distinct security processes, and confusing them can lead to critical vulnerabilities. Authentication is the process of verifying a user's claimed identity, essentially asking, "Are you who you say you are?" Once authenticated, authorization determines what resources that user can access and what actions they can perform, asking, "What are you allowed to do?" Implementing these patterns correctly is your first and most crucial line of defense against data breaches and unauthorized access.

Understanding the Core Distinction: AuthN vs. AuthZ

It is essential to internalize the difference between the two pillars of access security. Authentication (AuthN) establishes trust in a user's identity. Think of it like showing your passport at airport security; the officer verifies that the photo and details match the person presenting it. Common authentication factors include something you know (a password), something you have (a smartphone for a code), or something you are (a fingerprint). The system's goal here is to have high confidence that the entity making a request is legitimate.

Authorization (AuthZ), on the other hand, happens after authentication. It enforces policies about permissions. Using the airport analogy, once your identity is verified (authentication), your boarding pass (authorization) determines which gate you can go to, whether you can access the lounge, and which seat you can occupy on the plane. A common failure is to assume a successfully authenticated user is authorized to perform any action, which is how horizontal privilege escalation attacks occur—when User A accesses User B's private data because the system didn't check permissions after verifying identity.

Foundational Authentication Patterns

Web applications have evolved several primary patterns for managing authenticated user state.

Session-Based Authentication is a traditional and reliable pattern. When a user logs in with valid credentials, the server creates a unique session identifier (session ID) and stores session data (like the user's ID and role) in server-side memory or a database like Redis. This session ID is sent back to the user's browser, typically stored in a cookie. On subsequent requests, the browser sends the cookie; the server looks up the session ID to retrieve the stored authentication state. This pattern gives the server full control to invalidate sessions instantly but requires stateful management on the backend.

Token-Based Authentication with JWT is a modern, stateless alternative. Instead of storing data on the server, a compact, self-contained JSON Web Token (JWT) is issued upon login. A JWT is a string consisting of three encoded parts: a header (specifying the token type and signing algorithm), a payload (containing claims like user ID and expiration), and a signature. The server signs the token with a secret key. The client stores this token (often in local storage or a cookie) and sends it with each request, typically in the Authorization header as Bearer <token>. The server verifies the token's signature to ensure it hasn't been tampered with and trusts the claims within. This eliminates server-side storage but makes tokens difficult to revoke before their natural expiration.

Delegating Authentication with OAuth 2.0 and OpenID Connect

For scenarios where you don't want to manage passwords directly, OAuth 2.0 is the industry standard protocol for delegated authorization. While often used for "Login with Google/Facebook," its primary role is authorization. It allows a user to grant a third-party application (the Client) limited access to their resources hosted on another service (the Resource Server, like Google) without sharing their credentials. The key components are the Authorization Server (which issues tokens) and the Access Token (which the Client uses to access the API).

OpenID Connect (OIDC) is a thin identity layer built on top of OAuth 2.0 that adds authentication. When an OIDC flow completes, the Client receives an ID Token (a special type of JWT) containing verifiable claims about the user's identity, such as name and email. This combination allows you to securely outsource the authentication process to a trusted provider (like Google or Auth0) and then use standard tokens for authorization within your own application.

Implementing Authorization: RBAC and Beyond

After establishing identity, you must control access. Role-Based Access Control (RBAC) is the most common authorization model. Permissions are assigned to roles (e.g., Admin, Editor, Viewer), and users are assigned one or more roles. Your application checks if the user's role has the required permission before allowing an action. For instance, an Admin role might have delete:any_account permission, while a Viewer role only has read:own_profile. RBAC simplifies management but can become inflexible for complex, attribute-driven policies.

For more granular control, Attribute-Based Access Control (ABAC) evaluates policies against a set of attributes (user, resource, action, environment). For example, a policy could be: "A Doctor (user role) can view (action) a PatientRecord (resource) only if the record.department (resource attribute) matches doctor.department (user attribute)." While more powerful, ABAC is also more complex to implement and manage.

Enhancing Security with Multi-Factor Authentication

Relying solely on passwords is a significant risk. Multi-Factor Authentication (MFA) adds essential security layers by requiring two or more authentication factors from different categories. The common categories are Knowledge (something you know, like a PIN), Possession (something you have, like a phone app generating a Time-based One-Time Password (TOTP)), and Inherence (something you are, like a fingerprint). Even if a password is compromised, an attacker would still need the second factor to gain access. Implementing MFA, especially for administrative functions or sensitive data access, dramatically reduces the risk of account takeover attacks.

Common Pitfalls

1. Storing Tokens Insecurely: Storing JWTs in browser localStorage makes them vulnerable to XSS attacks. A more secure approach is to store them in an HttpOnly cookie (which JavaScript cannot access) or use the Backend-for-Frontend pattern. For session IDs, always use the Secure, HttpOnly, and SameSite cookie attributes.
2. Confusing OAuth Scope with Application Roles: An OAuth Access Token's scope (e.g., read:email) defines what the client app can do on the resource provider's API. It does not define the user's role within your application. You must decode your ID Token, use its sub (subject) claim to look up the user in your database, and then apply your own RBAC/ABAC logic.
3. Poor Session Management: Failing to implement proper session expiration (absolute and idle timeouts), not regenerating session IDs after login, and lacking secure session storage can lead to session hijacking and fixation attacks. Always treat session IDs as secrets.
4. Treating Authorization as an Afterthought: Baking permission checks directly into UI buttons is not sufficient. You must enforce authorization on every server-side API endpoint and data access point. The server must always re-verify that the authenticated principal has the right to perform the requested action on the target resource.

Summary

• Authentication (AuthN) verifies "who you are," while Authorization (AuthZ) controls "what you can do." They are sequential and equally critical security processes.
• Session-based authentication is stateful and server-controlled, while JWT-based authentication is stateless and client-held. Choose based on your need for immediate revocation versus scalability.
• OAuth 2.0 is a delegation protocol for authorization; OpenID Connect (OIDC) extends it to provide a standardized identity layer for authentication.
• Role-Based Access Control (RBAC) is a practical model for managing permissions by grouping them into roles assigned to users. For complex rules, consider Attribute-Based Access Control (ABAC).
• Multi-Factor Authentication (MFA) is a non-negotiable security enhancement that protects accounts by requiring proof from multiple independent categories.