Authentication & Authorization

Overview

Authentication (AuthN) and authorization (AuthZ) are distinct but tightly coupled security concerns. Authentication answers the question "Who are you?" by verifying a user's or service's identity through credentials, tokens, or certificates. Authorization answers the question "What are you allowed to do?" by determining whether an authenticated identity has permission to access a resource or perform an action. A secure system requires both: authentication without authorization means anyone who logs in can do anything, while authorization without authentication means permissions are assigned to identities that have not been verified. This skill covers the protocols, patterns, and best practices for implementing both concerns across all platforms and frameworks.

OAuth 2.0 Flows

OAuth 2.0 is an authorization framework that enables third-party applications to obtain limited access to a service on behalf of a resource owner. The choice of flow depends on the type of client and the security requirements.

Deprecated: The Implicit flow (returning tokens directly in the URL fragment) is deprecated in the OAuth 2.0 Security Best Current Practice (RFC 9700). Use Authorization Code + PKCE instead for all browser-based applications.

OpenID Connect (OIDC)

OpenID Connect is an identity layer built on top of OAuth 2.0 that adds authentication capabilities. While OAuth 2.0 only provides authorization (delegated access), OIDC enables the client to verify the user's identity.

• •ID Token: A JWT issued by the authorization server that contains claims about the authenticated user (e.g., sub, email, name, iat, exp). The ID token is intended for the client application, not for API access.
• •UserInfo Endpoint: An OAuth 2.0 protected resource that returns claims about the authenticated user. The client sends an access token to this endpoint to retrieve additional profile information.
• •Standard Claims: OIDC defines a set of standard claims including sub (subject identifier), name, email, email_verified, picture, locale, and updated_at. Custom claims can be added as needed.
• •Discovery Document: OIDC providers publish a /.well-known/openid-configuration document that clients use to dynamically discover endpoints, supported scopes, signing algorithms, and other provider capabilities.

Access Control Models

Zero Trust Architecture

Zero Trust is a security model that eliminates implicit trust based on network location. Rather than assuming that everything inside the corporate perimeter is safe, Zero Trust requires strict verification for every request regardless of its origin.

Core Principles (per NIST SP 800-207):

• •Never trust, always verify: Every access request must be authenticated and authorized, regardless of source network, IP address, or previous access history.
• •Least privilege access: Grant the minimum permissions necessary to perform the requested action. Use just-in-time and just-enough-access provisioning.
• •Assume breach: Design systems under the assumption that any component may already be compromised. Limit blast radius through segmentation and containment.
• •Microsegmentation: Divide the network and application into small, isolated segments. Enforce security policies at each segment boundary rather than only at the perimeter.
• •Continuous validation: Do not rely on a single point-in-time authentication. Continuously evaluate the security posture of devices, users, and sessions throughout their lifecycle.

Session Management

Secure session management prevents attackers from hijacking, fixating, or replaying user sessions.

Cookie Security Attributes:

Token Storage Guidance:

• •Web applications: Store tokens in HttpOnly, Secure cookies. Avoid localStorage and sessionStorage for access tokens (vulnerable to XSS).
• •Mobile applications: Use platform-secure storage (iOS Keychain, Android Keystore). Never store tokens in plaintext or shared preferences.
• •SPAs: Use the Backend-for-Frontend (BFF) pattern where a server-side component handles tokens and issues session cookies to the browser.

Session Lifecycle: Regenerate session IDs after authentication; enforce absolute and idle timeouts; invalidate sessions on logout both client-side and server-side; maintain a server-side session store for revocation capability.

Multi-Factor Authentication (MFA)

MFA requires users to present two or more verification factors from different categories: something you know (password), something you have (device/token), or something you are (biometric).

JWT Best Practices

JSON Web Tokens (JWTs) are widely used for stateless authentication and authorization. Improper use of JWTs is a common source of security vulnerabilities.

• •Signing algorithms: Use asymmetric algorithms (RS256, ES256) for tokens that are verified by multiple services. Use HS256 only when the same service both signs and verifies. Never allow "alg": "none".
• •Expiry: Always set the exp (expiration) claim. Access tokens should be short-lived (5-15 minutes). Use refresh tokens for longer sessions.
• •Audience and issuer: Always set and validate the aud (audience) and iss (issuer) claims to prevent token misuse across services.
• •Claims: Include only the minimum necessary claims in the payload. JWTs are signed, not encrypted by default -- their contents are readable by anyone with the token.
• •Never store sensitive data in the payload: Do not include passwords, secrets, PII, or other sensitive information in JWT claims. Use the token as a reference to server-side state if sensitive data is needed.
• •Token revocation: JWTs are stateless and cannot be individually revoked. Implement a token deny-list (blocklist) for critical revocation scenarios, or use short expiry times with refresh token rotation.
• •Key rotation: Rotate signing keys periodically. Use the kid (Key ID) header to support multiple active keys during rotation. Publish public keys via a JWKS (JSON Web Key Set) endpoint.

Best Practices

• •Use established protocols: implement OAuth 2.0 and OpenID Connect rather than designing custom authentication schemes. Custom auth is almost always less secure than battle-tested standards.
• •Always use PKCE: regardless of client type, use PKCE with the Authorization Code flow. It adds protection against code interception attacks at negligible implementation cost.
• •Enforce MFA for all privileged accounts: at minimum, require MFA for administrators, operators, and any account with access to sensitive data or infrastructure. Prefer phishing-resistant methods (WebAuthn/FIDO2).
• •Implement token rotation: use short-lived access tokens paired with longer-lived refresh tokens that are rotated on each use (refresh token rotation). Detect and revoke token families on reuse.
• •Centralize identity management: use a dedicated identity provider (IdP) rather than implementing authentication in each service. This provides a single point for policy enforcement, auditing, and credential management.
• •Apply least privilege at every layer: combine RBAC or ABAC with resource-level authorization checks. Never rely solely on role membership -- validate that the specific user has access to the specific resource being requested.
• •Secure the session lifecycle end-to-end: regenerate session identifiers after login, enforce idle and absolute timeouts, invalidate sessions on both client and server during logout, and use secure cookie attributes on every session cookie.
• •Log all authentication events: record successful logins, failed attempts, token issuance, refresh, revocation, and privilege changes. Feed these events into monitoring systems to detect credential stuffing, brute force attacks, and anomalous access patterns.