Authentication and Authorization Patterns

Authentication vs Authorization: Separating Concerns

Authentication answers 'who are you?' Authorization answers 'what can you do?' Conflating these concerns leads to tangled code where permission checks are embedded in login logic and identity management is mixed with access control. Separate them architecturally: authentication produces an identity (a user ID and associated claims), and authorization evaluates whether that identity has permission for a specific action on a specific resource.

This separation enables independent evolution. Authentication methods can change -- adding SSO, switching from passwords to passkeys, integrating biometric verification -- without modifying authorization logic. Authorization policies can change -- adding a new role, restricting access to a feature, implementing data-level permissions -- without touching the authentication system. Most security vulnerabilities in web applications stem from confused or incomplete implementation of one of these concerns.

Use dedicated libraries or services for each concern. For authentication: Auth0, Clerk, Firebase Auth, or open source alternatives like Keycloak handle identity management, social login, MFA, and session management. For authorization: implement RBAC or ABAC in your application code, or use policy engines like Open Policy Agent (OPA) or Cedar for complex authorization requirements. Separating these concerns into distinct system components makes each one simpler and more testable.

Modern Authentication Implementation

OAuth 2.0 with PKCE (Proof Key for Code Exchange) is the current standard for web application authentication. The Authorization Code flow with PKCE replaces the implicit flow, which is now deprecated due to token exposure in browser history and URLs. Use a well-maintained library -- do not implement OAuth flows from scratch. The security nuances are substantial and implementation errors create exploitable vulnerabilities.

JWTs (JSON Web Tokens) are the standard format for access tokens. A JWT contains a header, payload, and signature. The payload includes claims about the user -- user ID, email, roles, and token expiration. The signature ensures the token has not been tampered with. Use short-lived access tokens (15-60 minutes) paired with long-lived refresh tokens (days to weeks). When the access token expires, the client uses the refresh token to obtain a new one without requiring the user to re-authenticate.

Passkeys, built on the WebAuthn standard, are replacing passwords for consumer applications. Passkeys use public key cryptography -- the user's device stores a private key and the server stores the public key. This eliminates phishing, credential stuffing, and password database breaches because there is no shared secret to steal. Apple, Google, and Microsoft all support passkeys across their platforms, and adoption is accelerating. For new consumer products, passkey-first authentication provides stronger security with less user friction than password-based systems.

Role-Based Access Control (RBAC)

RBAC assigns permissions to roles, and roles to users. A typical SaaS product defines roles like Admin, Editor, and Viewer, each with a set of allowed actions. This model is simple to implement, easy to understand, and sufficient for most applications. The key design decision is granularity: coarse-grained roles (admin vs. user) are easier to manage but less flexible than fine-grained roles (can_edit_invoices, can_view_reports, can_manage_users).

Implement RBAC with a permissions table that maps roles to specific actions on specific resources. Check permissions at the API layer -- before executing any business logic -- to ensure that unauthorized requests are rejected early. A middleware or decorator pattern works well: @requires_permission('invoices:write') on an endpoint handler. This approach makes permission requirements visible in the code and prevents developers from accidentally omitting checks.

For multi-tenant SaaS, roles are scoped to an organization. A user might be an Admin in one organization and a Viewer in another. The permission check must include both the user's role within the specific organization and the action being attempted. Store role assignments with an organization_id to prevent cross-tenant role confusion. Most authorization bugs in multi-tenant applications stem from checking the user's role without verifying the organizational context.

Attribute-Based Access Control (ABAC)

ABAC extends RBAC by evaluating policies based on attributes of the user, the resource, the action, and the environment. Instead of a static role check, an ABAC policy might say: 'Users in the Finance department can approve invoices under $10,000 during business hours.' This granularity handles complex authorization requirements that RBAC cannot express without creating hundreds of roles. AWS IAM uses ABAC extensively, allowing policies based on resource tags, request conditions, and user attributes.

ABAC policies are expressed as rules evaluated at runtime. Policy engines like OPA (Open Policy Agent) and AWS Cedar provide domain-specific languages for writing and evaluating authorization policies. OPA uses Rego, a purpose-built policy language. Cedar uses a declarative syntax designed for readability. Both engines can evaluate thousands of policies per millisecond, making them suitable for inline authorization checks in request processing pipelines.

The tradeoff between RBAC and ABAC is complexity versus expressiveness. RBAC is simple to audit -- list all users with the Admin role and you know who has elevated access. ABAC policies interact in complex ways that make auditing harder -- understanding what a specific user can do requires evaluating all applicable policies against their attributes. Start with RBAC and add ABAC only for specific use cases that require attribute-based conditions, keeping the overall authorization model as simple as the business requirements allow.

API Security and Token Management

Secure API authentication requires attention to token storage, transmission, and lifecycle. Store tokens in httpOnly cookies with Secure and SameSite attributes to prevent XSS and CSRF attacks. Never store tokens in localStorage -- any JavaScript running on the page can access localStorage, making it vulnerable to XSS attacks. The httpOnly flag prevents JavaScript access to the cookie entirely, which is the strongest browser-side protection available.

Implement token rotation for refresh tokens. When a refresh token is used to obtain a new access token, issue a new refresh token simultaneously and invalidate the old one. If a refresh token is stolen and used, the legitimate user's next token rotation attempt will fail with an invalidated token, alerting the system to potential compromise. This rotation pattern limits the window of exposure for stolen refresh tokens.

Rate limit authentication endpoints aggressively. Login, token refresh, and password reset endpoints are primary targets for brute force and credential stuffing attacks. Implement progressive delays after failed attempts -- 1 second after the first failure, 2 seconds after the second, doubling up to a maximum. Combine rate limiting with account lockout after 10 consecutive failures, requiring email verification to restore access. OWASP's authentication cheat sheet provides detailed guidance on defensive implementation patterns.