OAuth Authentication FAQ & Answers

OAuth 2.1 (draft-ietf-oauth-v2-1-14, Oct 2025): consolidation of OAuth 2.0 best practices into single specification, not a new protocol but formalization of RFC 9700 security recommendations. Key changes from OAuth 2.0: (1) PKCE mandatory for ALL clients using Authorization Code flow (public and confidential). (2) Implicit flow removed entirely (deprecated, insecure). (3) Resource Owner Password Credentials flow removed (deprecated, anti-pattern). (4) Exact redirect URI matching required (no wildcards). (5) Refresh token sender constraint recommended. (6) Bearer token usage clarified with DPoP support. (7) Security best practices integrated throughout. Status: draft-14 as of Oct 2025, not yet final RFC but widely adopted (Anthropic MCP uses OAuth 2.1). Migration: if already using PKCE + no Implicit/ROPC flows, you're OAuth 2.1 compliant. Benefits: simpler specification (3 flows instead of 6), more secure by default, aligns with modern practices. Implementation: treat as current standard even while draft. Essential OAuth evolution toward security-first design.

OAuth 2.0: 'authorization framework enabling third-party applications to obtain limited access to HTTP service, either on behalf of resource owner by orchestrating approval interaction, or by allowing third-party application to obtain access on its own behalf' (RFC 6749). Purpose: delegated authorization (not authentication). Flow: (1) Client requests authorization from resource owner. (2) Resource owner grants authorization. (3) Client receives authorization grant. (4) Client exchanges grant for access token from authorization server. (5) Authorization server authenticates client and validates grant. (6) Client uses access token to access protected resources on resource server. Key principle: client never sees user credentials. OAuth 2.1 (draft-14, Oct 2025) consolidates best practices: PKCE mandatory for all clients, Implicit/ROPC flows removed. Use for: third-party API access, social login, microservices authorization. Modern security: RFC 9700 (Jan 2025) mandates HTTPS, exact redirect URI matching, state parameter for CSRF protection.

OAuth 2.0 roles (RFC 6749, RFC 9700): (1) Resource Owner: entity capable of granting access to protected resource (typically end-user). (2) Client: application making protected resource requests on behalf of resource owner. Client types: confidential (web apps with backend, can keep secrets) or public (SPAs, mobile apps, cannot keep secrets). (3) Authorization Server: server issuing access tokens to client after successfully authenticating resource owner and obtaining authorization. Issues both access tokens and refresh tokens. (4) Resource Server: server hosting protected resources, validates access tokens and responds to authorized requests. Authorization Server and Resource Server often same deployment but conceptually separate. Example: user (Resource Owner) authorizes Postman (Client) via Auth0 (Authorization Server) to access GitHub API (Resource Server). OAuth 2.1 clarifies client types must use appropriate flows: confidential clients can use client credentials, public clients must use PKCE. Understanding roles essential for secure implementation.

Authorization Code flow: most secure OAuth 2.0 grant type, obtains both access and refresh tokens (RFC 6749). Flow: (1) Client redirects user to /authorize endpoint with client_id, redirect_uri, scope, state, code_challenge (PKCE). (2) User authenticates and consents. (3) Authorization server redirects to redirect_uri with authorization code and state. (4) Client validates state, exchanges code + code_verifier for access token at /token endpoint (server-side). (5) Client uses access token in Authorization: Bearer header. Benefits: authorization code short-lived (60 seconds), token exchange happens server-side (secure), supports refresh tokens. OAuth 2.1 mandates PKCE for all Authorization Code flows (prevents 100% of code interception attacks). Use for: web apps with backend, mobile apps, native apps, SPAs with BFF pattern. Implementation: GET /authorize?response_type=code&client_id=...&code_challenge=SHA256(verifier). Essential flow for user-delegated authorization.

PKCE (Proof Key for Code Exchange, RFC 7636): extension to Authorization Code flow preventing authorization code interception attacks. How it works: (1) Client generates cryptographically random code_verifier (43-128 characters). (2) Creates code_challenge = BASE64URL(SHA256(code_verifier)). (3) Sends code_challenge + code_challenge_method=S256 in /authorize request. (4) Receives authorization code. (5) Sends code_verifier in /token request. (6) Authorization server verifies SHA256(code_verifier) matches stored code_challenge, then issues access token. Security: prevents 100% of authorization code interception attacks even if attacker intercepts code (cannot use without code_verifier). OAuth 2.1 mandates PKCE for ALL clients (public and confidential). RFC 9700 (Jan 2025): 'clients MUST use code_challenge, authorization servers MUST enforce.' Implementation: code_verifier must be 43-128 chars, use S256 method (not plain). Use for: mobile apps, SPAs, native apps, CLI tools, even server-side apps. Essential security control.

Implicit flow: simplified OAuth 2.0 flow designed for browser-based apps, returns access token directly in URL fragment (RFC 6749). Flow: GET /authorize?response_type=token → redirects to redirect_uri#access_token=... (no code exchange). Why deprecated: (1) Access tokens exposed in browser history and referer headers. (2) No refresh tokens allowed (security limitation). (3) No client authentication possible. (4) Vulnerable to XSS attacks (JavaScript can access token). (5) Authorization Code + PKCE provides same UX with better security. RFC 9700 (Jan 2025): 'Implicit grant MUST NOT be used.' OAuth 2.1 removes Implicit flow entirely from specification. Migration path: Authorization Code + PKCE for SPAs (same redirect-based flow, more secure). Modern alternative: BFF (Backend-For-Frontend) pattern with httpOnly cookies. Legacy apps: migrate immediately, major security risk. Never use for new applications. Understanding explains OAuth security evolution.

Client Credentials flow: OAuth 2.0 grant for machine-to-machine authentication where client acts on its own behalf (not delegating user access), RFC 6749. Flow: POST /token with grant_type=client_credentials, client_id, client_secret → receives access token. No user involvement, no refresh tokens (get new access token when expired). Authentication methods: (1) client_secret_basic: Authorization: Basic base64(client_id:client_secret). (2) client_secret_post: credentials in request body. (3) private_key_jwt: asymmetric keys (more secure). Use cases: microservices communication, API-to-API calls, scheduled jobs, CI/CD pipelines, backend services. Access token represents client's identity and scopes. Security: client_secret must be protected (store in secrets manager like AWS Secrets Manager, Azure Key Vault), rotate every 90 days, use mTLS for additional security. Example: POST /token with client_id=service-a&client_secret=secret&grant_type=client_credentials&scope=api:read. Confidential clients only. Essential for service-to-service authorization.

Access token: credential used to access protected resources, represents authorization issued to client (RFC 6749, RFC 6750). Format: JWT (self-contained with claims) or opaque reference token (requires introspection). JWT structure: header.payload.signature, payload contains sub (user ID), scope, exp (expiration), iss (issuer), aud (audience). Usage: Authorization: Bearer header in API requests. Lifetime: 15-60 minutes recommended (Okta 2025: access tokens 15 min, refresh continuously). Security: (1) HTTPS mandatory (prevents MITM). (2) Short expiration (limits blast radius if leaked). (3) Use DPoP for sender-constraint (RFC 9449, prevents token replay attacks). (4) Never store in localStorage (XSS risk). (5) Validate signature, exp, iss, aud on every request. Storage: in-memory (SPAs), httpOnly cookie with BFF pattern, server-side encrypted storage. Token binding: DPoP (Demonstrating Proof of Possession) recommended over mTLS for scalability. Treat as opaque on client side. Essential OAuth credential.

Refresh token: long-lived credential for obtaining new access tokens without user re-authentication (RFC 6749). Flow: POST /token with grant_type=refresh_token&refresh_token= → receives new access_token + new refresh_token (if rotation enabled). Refresh Token Rotation (Auth0 2025): every refresh request returns new refresh token and invalidates previous one, detects token reuse attacks. If reused token detected: revoke entire token family (all associated tokens). Lifetime: 7 days typical, absolute expiration set at creation (does not extend with rotation). Security: (1) Store server-side only (never client-side localStorage). (2) One-time use with rotation (prevents replay). (3) Bind to client_id. (4) Revocable via /revoke endpoint. (5) Use shortest reuse interval (Auth0 recommends minimal grace period). Use for: SPAs with BFF pattern, mobile apps, long-lived sessions. Implementation: enable offline_access scope. Auth0 2025: rotation makes refresh tokens acceptable for SPAs. Essential for continuous access without login prompts.

Scopes: space-delimited permissions limiting access token's privileges to protected resources (RFC 6749). Format: scope parameter in authorization request, included in access token. Example: scope='openid profile email read:orders write:cart' (space-delimited). Naming conventions: action:resource format (read:email, write:profile, admin:users). Benefits: principle of least privilege, user consent transparency, granular permissions. Google 2025 best practices: (1) 'Use incremental authorization to request appropriate OAuth scopes when functionality needed' (don't request all upfront). (2) 'OAuth scopes should be made as granular as possible to prevent excessive permissions.' (3) Document each scope's purpose clearly. Validation: resource server must validate scopes in access token match required permissions. Standard OIDC scopes: openid (required for OIDC), profile (name, picture), email, address, phone. Custom scopes: api:read, api:write, admin:all. Scope downgrade: never grant more than requested. Use for: API authorization, user consent, audit logging. Essential OAuth security control.

State parameter: CSRF protection mechanism for OAuth authorization requests (RFC 6749, RFC 9700). Flow: (1) Client generates cryptographically random state value (minimum 128 bits, use crypto.randomBytes(32).toString('hex')). (2) Stores state in session or cookie tied to user. (3) Includes state in /authorize request. (4) Authorization server returns unchanged state in redirect callback. (5) Client validates returned state matches stored value exactly. Attack prevented: CSRF where attacker tricks victim into authorizing attacker's account linkage (session fixation). RFC 9700 (Jan 2025): 'Clients MUST use state parameter or other countermeasures for CSRF protection.' Implementation: const state = crypto.randomUUID(); store in httpOnly cookie with SameSite=Lax; validate on callback. Additional use: encode application state (redirect URL after login, user preferences). Never reuse state values. Combine with PKCE for defense-in-depth. Essential security parameter for all OAuth flows.

Redirect URI: URL where authorization server sends user with authorization code or tokens after authorization (RFC 6749). Security critical: controls where sensitive data delivered. RFC 9700 (Jan 2025) requirements: (1) 'Authorization servers MUST utilize exact string matching when comparing client redirect URIs against pre-registered URIs' (no substring/pattern matching). (2) Pre-register all redirect URIs (whitelist only). (3) HTTPS mandatory for production (except http://localhost for development). (4) No wildcards () allowed (e.g., https://.example.com forbidden). (5) No open redirects (verify redirect_uri parameter matches registered exactly). Attacks prevented: authorization code interception, token theft via malicious redirects. Configuration examples: Web: https://app.example.com/callback, Mobile: myapp://callback (custom scheme) or https://app.example.com/mobile (universal links preferred). Localhost: http://localhost:3000/callback or http://127.0.0.1:3000/callback. Validation: if (redirect_uri !== registeredURIs.find(u => u === redirect_uri)) throw error. Essential OAuth security control.

OAuth 2.0 vs OAuth 1.0 (RFC 6749 vs RFC 5849): OAuth 2.0 (current standard): bearer tokens (Authorization: Bearer ), HTTPS mandatory for security, no cryptographic signatures required, multiple grant types (authorization code, client credentials, device flow), JSON responses, clearer role separation, extensible architecture. OAuth 1.0 (deprecated): request signatures using HMAC-SHA1 (complex), works without HTTPS (signatures provide integrity), single flow only, harder to implement. Benefits of 2.0: simpler implementation (no signature complexity), better mobile/SPA/IoT support, modular grant types, wider adoption. Security trade-offs: OAuth 1.0 signatures protect without HTTPS; OAuth 2.0 simpler but requires HTTPS (bearer tokens vulnerable if intercepted). Migration: OAuth 1.0 fully deprecated, all new implementations use OAuth 2.0. Current state: OAuth 1.0 only in legacy systems (old Twitter API v1), OAuth 2.0 universal industry standard. OAuth 2.1 further modernizes 2.0 with mandatory PKCE. Understanding explains protocol evolution toward simplicity and HTTPS-everywhere.

OpenID Connect (OIDC): identity authentication layer built on OAuth 2.0, provides user authentication while OAuth handles authorization (OpenID Connect Core 1.0, ISO/IEC 26131:2024). Key difference: OAuth answers 'what can you access?', OIDC answers 'who are you?'. Token additions: (1) ID Token: JWT with user claims (sub=user ID, name, email, iat, exp, iss, aud). (2) UserInfo endpoint: GET /userinfo returns additional profile claims. Flow: Authorization Code with scope=openid → returns access_token + id_token. Standard scopes: openid (required for OIDC), profile (name, picture, etc.), email, address, phone. ID token validation: verify signature, iss (issuer), aud (client_id), exp (not expired), nonce (CSRF protection). Use cases: SSO (enterprise), social login (Sign in with Google/GitHub), authentication for SPAs. Providers: Auth0, Okta, Azure AD, Google, GitHub. Example: scope='openid profile email' returns ID token with sub, name, email claims. OIDC = authentication, OAuth 2.0 = authorization. Essential for identity verification.

JWT (JSON Web Token, RFC 7519): compact, URL-safe token format for representing claims, commonly used for OAuth access tokens and OIDC ID tokens. Structure: header.payload.signature (three Base64URL-encoded parts). Header: {"alg":"RS256","typ":"JWT"}. Payload: claims (sub=user ID, exp=expiration, iat=issued at, iss=issuer, aud=audience, scope=permissions). Signature: HMAC or RSA signature for integrity verification. Validation (RFC 8725 2025): (1) Verify signature using public key/secret. (2) Check algorithm claim against allowlist (prevent 'none' attack). (3) Validate exp (not expired), nbf (not before). (4) Verify iss matches trusted issuer. (5) Verify aud matches expected audience (client_id). (6) Check jti (JWT ID) for replay prevention. Algorithms: RS256/ES256 (asymmetric, preferred), EdDSA (newest, quantum-resistant). Security: JWTs are base64-decoded (readable), don't store secrets. Expiration: 15 min for access tokens, 1 hour for ID tokens. Use for: self-contained access tokens, OIDC ID tokens. Alternative: opaque tokens (reference tokens with introspection). Essential OAuth token format.

OAuth 2.0 security best practices (RFC 9700, Jan 2025): (1) 'Always use HTTPS' for all endpoints and redirects (prevents MITM). (2) PKCE mandatory for all clients using Authorization Code (public and confidential). (3) 'Clients MUST use state parameter' for CSRF protection in authorization requests. (4) 'Authorization servers MUST use exact string matching' for redirect URI validation (no wildcards). (5) Short-lived access tokens (15-60 min, Okta 2025: 15 min standard). (6) Refresh token rotation with automatic reuse detection (invalidate token family on reuse). (7) 'Implicit grant MUST NOT be used' (removed in OAuth 2.1). (8) Validate tokens on every request: signature, exp, iss, aud, scope. (9) Granular scopes following least privilege. (10) Never store tokens in localStorage (XSS risk), use httpOnly cookies or in-memory. (11) DPoP (RFC 9449) for sender-constrained tokens (prevents token replay). (12) Implement /revoke endpoint for token revocation. (13) Rate limiting on token endpoints. (14) Audit logging for security events. (15) Regular security reviews and penetration testing. Following prevents authorization code interception, CSRF, token theft, and replay attacks.

Common OAuth 2.0 vulnerabilities (RFC 9700): (1) Authorization code interception: attacker steals code from redirect URL (mitigate: PKCE mandatory, 100% prevention). (2) CSRF attacks: attacker tricks user into authorizing attacker's linkage (mitigate: state parameter validation). (3) Open redirect: malicious redirect_uri bypasses validation (mitigate: exact string matching, no wildcards). (4) Token leakage: tokens exposed in browser history, referer headers, logs (mitigate: short expiration 15-60 min, HTTPS only, httpOnly cookies). (5) Insufficient redirect URI validation: partial matching allows attacker domains (mitigate: whitelist with exact matching). (6) Token replay: stolen token reused by attacker (mitigate: DPoP sender-constraint, short lifetime). (7) XSS token theft: JavaScript accesses localStorage tokens (mitigate: never use localStorage, httpOnly cookies, CSP headers). (8) Phishing: fake authorization page captures credentials (mitigate: user education, system browser on mobile). (9) Mix-up attacks: client confused about which authorization server issued token (mitigate: validate iss claim). Understanding enables secure implementation following RFC 9700 best practices.

SSO (Single Sign-On) with OIDC: user authenticates once to identity provider (IdP), accesses multiple applications without re-authentication. Flow: (1) User visits App A, clicks 'Sign in'. (2) App A redirects to IdP /authorize endpoint. (3) User authenticates to IdP (username/password, MFA, passkey). (4) IdP creates SSO session (httpOnly cookie, 8-hour lifetime). (5) IdP redirects to App A with authorization code. (6) App A exchanges code for access_token + id_token. (7) User visits App B, redirects to same IdP. (8) IdP recognizes active SSO session (no re-authentication). (9) IdP issues new authorization code for App B. (10) App B gets tokens, user logged in. Session management: prompt=none for silent authentication check, prompt=login to force re-authentication. Logout: RP-initiated logout (end_session_endpoint) or front-channel/back-channel logout. Protocols: OIDC (modern), SAML (legacy enterprise). IdPs: Okta, Auth0, Azure AD, Google Workspace. Use for: enterprise SaaS, multi-application environments. Essential for unified user experience.

Secure token storage by client type (Okta 2025): (1) Web apps (server-side): encrypted database, secrets manager (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault), server-side sessions. Never client-side. (2) SPAs: BFF (Backend-For-Frontend) pattern with httpOnly cookies (best) or in-memory storage (lost on refresh). NEVER localStorage/sessionStorage (XSS steals tokens). (3) Mobile apps: iOS Keychain (secure enclave), Android Keystore (hardware-backed), encrypted SharedPreferences. (4) Desktop apps: OS credential store (Windows Credential Manager, macOS Keychain). 'Refresh tokens should not be stored client-side; only securely in backend.' Cookie attributes for web: httpOnly (no JavaScript access), Secure (HTTPS only), SameSite=Strict (CSRF protection), short Max-Age. Access tokens: in-memory or short-lived cookies. Best practices: (1) Encrypt at rest (AES-256). (2) Never log tokens (redact in logs). (3) Clear on logout. (4) Use secrets rotation. (5) DPoP binding for additional security. Storage anti-patterns: localStorage, sessionStorage, unencrypted databases, query parameters. Essential security control.

Mobile OAuth security (RFC 8252, RFC 9700): (1) Authorization Code flow + PKCE mandatory for native apps. (2) System browser required (NOT embedded WebView): iOS ASWebAuthenticationSession (iOS 12+), Android Chrome Custom Tabs. Benefits: user can verify authorization page, shared cookies, more secure than WebView. (3) Redirect URI: Custom URL schemes (myapp://callback) or universal/app links (https://app.example.com/callback, preferred). Register scheme in app manifest. (4) Token storage: iOS Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly, Android Keystore (hardware-backed), encrypt refresh tokens. (5) No client_secret (public client, app is decompilable). (6) Token lifetime: access tokens 60 min, refresh token rotation enabled. (7) Biometric re-authentication for sensitive operations. (8) Certificate pinning for API calls (prevent MITM). RFC 9700: 'Public clients like native apps MUST use PKCE.' Anti-patterns: embedded WebView (phishing risk), storing secrets in app, using Implicit flow. Example redirect: myapp://callback?code=abc&state=xyz. Essential for mobile security.

SPA OAuth security (RFC 9700): (1) Authorization Code flow + PKCE mandatory (NOT Implicit flow). (2) Token storage options: BFF (Backend-For-Frontend) pattern with httpOnly cookies (most secure) or in-memory storage (lost on page refresh). NEVER localStorage (XSS risk). (3) BFF pattern: SPA calls backend proxy → backend exchanges code for tokens → backend stores tokens server-side → backend issues httpOnly session cookie to SPA. Benefits: tokens never exposed to JavaScript. (4) No client_secret (public client, JavaScript is readable). (5) Silent authentication: hidden iframe with prompt=none or refresh token via BFF. (6) Security headers: Content-Security-Policy: default-src 'self' (XSS protection), X-Frame-Options: DENY. (7) CORS configured on resource server (Access-Control-Allow-Origin). (8) Short token lifetime (15 min access tokens). (9) State parameter for CSRF. RFC 9700: 'Browser-based apps MUST use PKCE.' Modern recommendation: PKCE + BFF + httpOnly cookies. Example: fetch('/api/auth/login') → backend handles OAuth → returns session cookie. Essential SPA security pattern.

Token introspection (RFC 7662): method for resource server to query authorization server about access token's current state and metadata. Endpoint: POST /introspect with token parameter + optional token_type_hint. Response: {"active": true, "scope": "read write", "client_id": "client123", "username": "user", "exp": 1735689600, "iat": 1735686000, "sub": "user-id"}. Use cases: (1) Opaque tokens (reference tokens): resource server cannot decode token locally, must introspect for metadata. (2) Real-time revocation checking: verify token not revoked even if JWT (JWTs are self-contained but revocation requires server check). (3) Multi-tenant validation: verify token belongs to correct tenant/organization. (4) Additional claims: retrieve user info, roles, permissions not in token. Authentication: resource server authenticates to introspection endpoint with client credentials. Performance: adds network latency on every API request. Optimization: cache introspection results for token's remaining lifetime (check exp - iat). JWT vs opaque: JWT allows local validation (no introspection), opaque requires introspection. Use introspection for: opaque tokens, revocation checking, server-side validation. Essential for opaque token architectures.

Token revocation (RFC 7009): mechanism for clients to notify authorization server that token should no longer be valid. Endpoint: POST /revoke with token parameter + optional token_type_hint (access_token or refresh_token). Request: client authenticates with client_id + client_secret, sends token to revoke. Response: HTTP 200 (success) or appropriate error. Revocable: access tokens, refresh tokens. Behavior: revoking refresh token should revoke all associated access tokens (token family). Use cases: (1) User logout: revoke all user's tokens. (2) Security incident: immediately invalidate compromised token. (3) Permission changes: revoke and reissue with new scopes. (4) Account suspension: revoke all user tokens. JWT limitations: self-contained JWTs cannot be revoked without server-side deny-list or requiring introspection on every request. Opaque tokens: easily revocable (database lookup). Best practices: (1) Implement /revoke endpoint. (2) Short-lived access tokens (15-60 min reduces revocation urgency). (3) Revoke refresh tokens on logout. (4) Cascade revocation (refresh token → all access tokens). (5) Audit log all revocations. (6) Rate limit revocation endpoint. Token family revocation critical for refresh token rotation security. Essential for security compliance.

Resource Owner Password Credentials (ROPC) flow: client directly collects and sends user's username + password to authorization server for access token (RFC 6749). Flow: POST /token with grant_type=password&username=user&password=pass&client_id=...&scope=... → receives access_token. Why deprecated: (1) Client sees user credentials (violates OAuth delegation principle). (2) Credentials directly exposed to client (phishing risk). (3) No MFA/2FA support (bypasses security). (4) No user consent screen (no transparency). (5) Difficult to revoke per-app access (all-or-nothing). (6) Stores passwords in client (security risk). (7) Cannot use SSO/federated identity. OAuth 2.1 removes ROPC entirely. When previously acceptable: highly-trusted first-party apps (same organization), legacy migration only. Modern alternatives: Authorization Code + PKCE (redirect-based), Device Authorization Grant (RFC 8628) for input-constrained devices. Migration path: replace ROPC with Authorization Code + PKCE, implement redirect flow. Best practice: never use ROPC for new applications, migrate away immediately. Security note: ROPC contradicts OAuth's core security model. Understanding explains OAuth anti-patterns.

OAuth consent screen: UI shown during authorization where user grants/denies requested permissions to client application (RFC 6749). Components displayed: (1) Client identification: app name, logo, publisher/developer name, verified badge (if applicable). (2) Scope descriptions: user-friendly explanation of each requested permission (e.g., 'read:email' → 'View your email address'). (3) Account selection: which user account to authorize. (4) Consent buttons: 'Allow' and 'Deny'. Google 2025 best practices: (1) 'Use incremental authorization to request appropriate OAuth scopes when functionality needed' (request scopes progressively, not all upfront). (2) Granular scope descriptions in plain language. (3) Highlight sensitive/dangerous scopes (access to private data, write permissions). (4) Allow partial consent (user can uncheck specific scopes). (5) Remember consent (prompt_consent=false for returning users). (6) Easy revocation via user account settings. (7) Show data access frequency/last access. Implementation: authorization server renders consent screen at /authorize endpoint. Branding: customize app name, logo, privacy policy link. User experience: minimal friction, clear security indicators. Regulatory: GDPR requires explicit, informed consent. Consent storage: record user consent decisions with timestamp, scope list. Withdrawal: implement consent revocation endpoint. Essential for user trust, security transparency, and legal compliance.

Implicit flow returns access token directly in URL fragment, creating severe security vulnerabilities. Problems: (1) Access tokens exposed in browser history and referer headers. (2) No refresh tokens (security limitation). (3) No client authentication. (4) Vulnerable to XSS attacks (JavaScript can access token). (5) Authorization Code + PKCE provides same UX with better security. RFC 9700 (Jan 2025): 'Implicit grant MUST NOT be used.' OAuth 2.1 removes Implicit entirely. Migration: use Authorization Code + PKCE for SPAs (same redirect flow, more secure) or BFF pattern with httpOnly cookies. Legacy apps must migrate immediately - major security risk. Never use for new applications. Understanding explains OAuth security evolution.

Access token is credential for accessing protected resources, representing authorization issued to client (RFC 6749). Format: JWT (self-contained with claims) or opaque reference token (requires introspection). JWT payload contains: sub (user ID), scope, exp (expiration), iss (issuer), aud (audience). Usage: Authorization: Bearer header. Lifetime: 15-60 minutes recommended (Okta 2025: 15 min). Security: (1) HTTPS mandatory. (2) Short expiration limits blast radius. (3) Use DPoP for sender-constraint (RFC 9449, prevents replay). (4) Never store in localStorage (XSS risk). (5) Validate signature, exp, iss, aud on every request. Storage: in-memory (SPAs), httpOnly cookie with BFF, server-side encrypted. Essential OAuth credential.

Refresh token is long-lived credential for obtaining new access tokens without re-authentication (RFC 6749). Flow: POST /token with grant_type=refresh_token → receives new access_token + new refresh_token (if rotation enabled). Refresh Token Rotation (Auth0 2025): every refresh returns new token and invalidates previous. If reused token detected: revoke entire token family. Lifetime: 7 days typical, absolute expiration at creation. Security: (1) Store server-side only. (2) One-time use with rotation prevents replay. (3) Bind to client_id. (4) Revocable via /revoke. (5) Use shortest reuse interval. Use for: SPAs with BFF, mobile apps, long-lived sessions. Enable with offline_access scope. Rotation makes refresh tokens acceptable for SPAs.

Scopes are space-delimited permissions limiting access token privileges (RFC 6749). Format: scope='openid profile email read:orders write:cart'. Naming: action:resource (read:email, write:profile, admin:users). Google 2025 best practices: (1) Use incremental authorization - request scopes when functionality needed (not all upfront). (2) Make scopes as granular as possible to prevent excessive permissions. (3) Document each scope purpose clearly. Validation: resource server must validate token scopes match required permissions. Standard OIDC scopes: openid (required), profile, email, address, phone. Custom scopes: api:read, api:write, admin:all. Never grant more than requested (no scope upgrade). Use for: API authorization, user consent, audit logging. Essential security control.

State parameter provides CSRF protection for OAuth authorization requests (RFC 6749, RFC 9700). Flow: (1) Client generates random state (minimum 128 bits, use crypto.randomBytes(32).toString('hex')). (2) Stores state in session/cookie. (3) Includes state in /authorize request. (4) Server returns unchanged state in callback. (5) Client validates returned state matches stored value exactly. Attack prevented: CSRF where attacker tricks victim into authorizing attacker's account linkage. RFC 9700 (Jan 2025): 'Clients MUST use state parameter for CSRF protection.' Implementation: const state = crypto.randomUUID(); store in httpOnly cookie with SameSite=Lax. Never reuse state values. Combine with PKCE for defense-in-depth. Essential security parameter.

Redirect URI is where authorization server sends user with code/tokens after authorization (RFC 6749). RFC 9700 (Jan 2025) requirements: (1) 'Authorization servers MUST use exact string matching' for redirect URIs (no substring/pattern matching). (2) Pre-register all URIs (whitelist only). (3) HTTPS mandatory for production (except http://localhost for dev). (4) No wildcards (https://*.example.com forbidden). (5) No open redirects. Attacks prevented: code interception, token theft via malicious redirects. Examples: Web https://app.example.com/callback, Mobile myapp://callback or https://app.example.com/mobile (universal links preferred), Localhost http://localhost:3000/callback. Validation: exact match only. Essential security control.

OpenID Connect (OIDC) is identity authentication layer built on OAuth 2.0 (OpenID Connect Core 1.0, ISO/IEC 26131:2024). Key difference: OAuth answers 'what can you access?', OIDC answers 'who are you?'. Token additions: (1) ID Token - JWT with user claims (sub, name, email, iat, exp, iss, aud). (2) UserInfo endpoint - GET /userinfo returns profile claims. Flow: Authorization Code with scope=openid → returns access_token + id_token. Standard scopes: openid (required), profile, email, address, phone. ID token validation: verify signature, iss, aud (client_id), exp, nonce. Use cases: SSO, social login (Sign in with Google/GitHub), SPA authentication. Providers: Auth0, Okta, Azure AD, Google. OIDC = authentication, OAuth = authorization.

OAuth 2.0 security best practices (RFC 9700, Jan 2025): (1) Always use HTTPS for all endpoints. (2) PKCE mandatory for all Authorization Code flows. (3) State parameter required for CSRF protection. (4) Exact string matching for redirect URI validation (no wildcards). (5) Short-lived access tokens (15-60 min, Okta: 15 min standard). (6) Refresh token rotation with reuse detection. (7) Never use Implicit grant (removed in OAuth 2.1). (8) Validate tokens on every request: signature, exp, iss, aud, scope. (9) Granular scopes following least privilege. (10) Never store tokens in localStorage (XSS risk), use httpOnly cookies. (11) DPoP (RFC 9449) for sender-constrained tokens. (12) Implement /revoke endpoint. (13) Rate limiting on token endpoints. Following prevents code interception, CSRF, token theft, replay attacks.

OAuth 2.1 (draft-ietf-oauth-v2-1-14, Oct 2025): consolidation of OAuth 2.0 best practices into single specification, not a new protocol but formalization of RFC 9700 security recommendations. Key changes from OAuth 2.0: (1) PKCE mandatory for ALL clients using Authorization Code flow (public and confidential). (2) Implicit flow removed entirely (deprecated, insecure). (3) Resource Owner Password Credentials flow removed (deprecated, anti-pattern). (4) Exact redirect URI matching required (no wildcards). (5) Refresh token sender constraint recommended. (6) Bearer token usage clarified with DPoP support. (7) Security best practices integrated throughout. Status: draft-14 as of Oct 2025, not yet final RFC but widely adopted (Anthropic MCP uses OAuth 2.1). Migration: if already using PKCE + no Implicit/ROPC flows, you're OAuth 2.1 compliant. Benefits: simpler specification (3 flows instead of 6), more secure by default, aligns with modern practices. Implementation: treat as current standard even while draft. Essential OAuth evolution toward security-first design.

OAuth 2.0: 'authorization framework enabling third-party applications to obtain limited access to HTTP service, either on behalf of resource owner by orchestrating approval interaction, or by allowing third-party application to obtain access on its own behalf' (RFC 6749). Purpose: delegated authorization (not authentication). Flow: (1) Client requests authorization from resource owner. (2) Resource owner grants authorization. (3) Client receives authorization grant. (4) Client exchanges grant for access token from authorization server. (5) Authorization server authenticates client and validates grant. (6) Client uses access token to access protected resources on resource server. Key principle: client never sees user credentials. OAuth 2.1 (draft-14, Oct 2025) consolidates best practices: PKCE mandatory for all clients, Implicit/ROPC flows removed. Use for: third-party API access, social login, microservices authorization. Modern security: RFC 9700 (Jan 2025) mandates HTTPS, exact redirect URI matching, state parameter for CSRF protection.

OAuth 2.0 roles (RFC 6749, RFC 9700): (1) Resource Owner: entity capable of granting access to protected resource (typically end-user). (2) Client: application making protected resource requests on behalf of resource owner. Client types: confidential (web apps with backend, can keep secrets) or public (SPAs, mobile apps, cannot keep secrets). (3) Authorization Server: server issuing access tokens to client after successfully authenticating resource owner and obtaining authorization. Issues both access tokens and refresh tokens. (4) Resource Server: server hosting protected resources, validates access tokens and responds to authorized requests. Authorization Server and Resource Server often same deployment but conceptually separate. Example: user (Resource Owner) authorizes Postman (Client) via Auth0 (Authorization Server) to access GitHub API (Resource Server). OAuth 2.1 clarifies client types must use appropriate flows: confidential clients can use client credentials, public clients must use PKCE. Understanding roles essential for secure implementation.

Authorization Code flow: most secure OAuth 2.0 grant type, obtains both access and refresh tokens (RFC 6749). Flow: (1) Client redirects user to /authorize endpoint with client_id, redirect_uri, scope, state, code_challenge (PKCE). (2) User authenticates and consents. (3) Authorization server redirects to redirect_uri with authorization code and state. (4) Client validates state, exchanges code + code_verifier for access token at /token endpoint (server-side). (5) Client uses access token in Authorization: Bearer header. Benefits: authorization code short-lived (60 seconds), token exchange happens server-side (secure), supports refresh tokens. OAuth 2.1 mandates PKCE for all Authorization Code flows (prevents 100% of code interception attacks). Use for: web apps with backend, mobile apps, native apps, SPAs with BFF pattern. Implementation: GET /authorize?response_type=code&client_id=...&code_challenge=SHA256(verifier). Essential flow for user-delegated authorization.

PKCE (Proof Key for Code Exchange, RFC 7636): extension to Authorization Code flow preventing authorization code interception attacks. How it works: (1) Client generates cryptographically random code_verifier (43-128 characters). (2) Creates code_challenge = BASE64URL(SHA256(code_verifier)). (3) Sends code_challenge + code_challenge_method=S256 in /authorize request. (4) Receives authorization code. (5) Sends code_verifier in /token request. (6) Authorization server verifies SHA256(code_verifier) matches stored code_challenge, then issues access token. Security: prevents 100% of authorization code interception attacks even if attacker intercepts code (cannot use without code_verifier). OAuth 2.1 mandates PKCE for ALL clients (public and confidential). RFC 9700 (Jan 2025): 'clients MUST use code_challenge, authorization servers MUST enforce.' Implementation: code_verifier must be 43-128 chars, use S256 method (not plain). Use for: mobile apps, SPAs, native apps, CLI tools, even server-side apps. Essential security control.

Implicit flow: simplified OAuth 2.0 flow designed for browser-based apps, returns access token directly in URL fragment (RFC 6749). Flow: GET /authorize?response_type=token → redirects to redirect_uri#access_token=... (no code exchange). Why deprecated: (1) Access tokens exposed in browser history and referer headers. (2) No refresh tokens allowed (security limitation). (3) No client authentication possible. (4) Vulnerable to XSS attacks (JavaScript can access token). (5) Authorization Code + PKCE provides same UX with better security. RFC 9700 (Jan 2025): 'Implicit grant MUST NOT be used.' OAuth 2.1 removes Implicit flow entirely from specification. Migration path: Authorization Code + PKCE for SPAs (same redirect-based flow, more secure). Modern alternative: BFF (Backend-For-Frontend) pattern with httpOnly cookies. Legacy apps: migrate immediately, major security risk. Never use for new applications. Understanding explains OAuth security evolution.

Client Credentials flow: OAuth 2.0 grant for machine-to-machine authentication where client acts on its own behalf (not delegating user access), RFC 6749. Flow: POST /token with grant_type=client_credentials, client_id, client_secret → receives access token. No user involvement, no refresh tokens (get new access token when expired). Authentication methods: (1) client_secret_basic: Authorization: Basic base64(client_id:client_secret). (2) client_secret_post: credentials in request body. (3) private_key_jwt: asymmetric keys (more secure). Use cases: microservices communication, API-to-API calls, scheduled jobs, CI/CD pipelines, backend services. Access token represents client's identity and scopes. Security: client_secret must be protected (store in secrets manager like AWS Secrets Manager, Azure Key Vault), rotate every 90 days, use mTLS for additional security. Example: POST /token with client_id=service-a&client_secret=secret&grant_type=client_credentials&scope=api:read. Confidential clients only. Essential for service-to-service authorization.

Access token: credential used to access protected resources, represents authorization issued to client (RFC 6749, RFC 6750). Format: JWT (self-contained with claims) or opaque reference token (requires introspection). JWT structure: header.payload.signature, payload contains sub (user ID), scope, exp (expiration), iss (issuer), aud (audience). Usage: Authorization: Bearer header in API requests. Lifetime: 15-60 minutes recommended (Okta 2025: access tokens 15 min, refresh continuously). Security: (1) HTTPS mandatory (prevents MITM). (2) Short expiration (limits blast radius if leaked). (3) Use DPoP for sender-constraint (RFC 9449, prevents token replay attacks). (4) Never store in localStorage (XSS risk). (5) Validate signature, exp, iss, aud on every request. Storage: in-memory (SPAs), httpOnly cookie with BFF pattern, server-side encrypted storage. Token binding: DPoP (Demonstrating Proof of Possession) recommended over mTLS for scalability. Treat as opaque on client side. Essential OAuth credential.

Refresh token: long-lived credential for obtaining new access tokens without user re-authentication (RFC 6749). Flow: POST /token with grant_type=refresh_token&refresh_token= → receives new access_token + new refresh_token (if rotation enabled). Refresh Token Rotation (Auth0 2025): every refresh request returns new refresh token and invalidates previous one, detects token reuse attacks. If reused token detected: revoke entire token family (all associated tokens). Lifetime: 7 days typical, absolute expiration set at creation (does not extend with rotation). Security: (1) Store server-side only (never client-side localStorage). (2) One-time use with rotation (prevents replay). (3) Bind to client_id. (4) Revocable via /revoke endpoint. (5) Use shortest reuse interval (Auth0 recommends minimal grace period). Use for: SPAs with BFF pattern, mobile apps, long-lived sessions. Implementation: enable offline_access scope. Auth0 2025: rotation makes refresh tokens acceptable for SPAs. Essential for continuous access without login prompts.

Scopes: space-delimited permissions limiting access token's privileges to protected resources (RFC 6749). Format: scope parameter in authorization request, included in access token. Example: scope='openid profile email read:orders write:cart' (space-delimited). Naming conventions: action:resource format (read:email, write:profile, admin:users). Benefits: principle of least privilege, user consent transparency, granular permissions. Google 2025 best practices: (1) 'Use incremental authorization to request appropriate OAuth scopes when functionality needed' (don't request all upfront). (2) 'OAuth scopes should be made as granular as possible to prevent excessive permissions.' (3) Document each scope's purpose clearly. Validation: resource server must validate scopes in access token match required permissions. Standard OIDC scopes: openid (required for OIDC), profile (name, picture), email, address, phone. Custom scopes: api:read, api:write, admin:all. Scope downgrade: never grant more than requested. Use for: API authorization, user consent, audit logging. Essential OAuth security control.

State parameter: CSRF protection mechanism for OAuth authorization requests (RFC 6749, RFC 9700). Flow: (1) Client generates cryptographically random state value (minimum 128 bits, use crypto.randomBytes(32).toString('hex')). (2) Stores state in session or cookie tied to user. (3) Includes state in /authorize request. (4) Authorization server returns unchanged state in redirect callback. (5) Client validates returned state matches stored value exactly. Attack prevented: CSRF where attacker tricks victim into authorizing attacker's account linkage (session fixation). RFC 9700 (Jan 2025): 'Clients MUST use state parameter or other countermeasures for CSRF protection.' Implementation: const state = crypto.randomUUID(); store in httpOnly cookie with SameSite=Lax; validate on callback. Additional use: encode application state (redirect URL after login, user preferences). Never reuse state values. Combine with PKCE for defense-in-depth. Essential security parameter for all OAuth flows.

Redirect URI: URL where authorization server sends user with authorization code or tokens after authorization (RFC 6749). Security critical: controls where sensitive data delivered. RFC 9700 (Jan 2025) requirements: (1) 'Authorization servers MUST utilize exact string matching when comparing client redirect URIs against pre-registered URIs' (no substring/pattern matching). (2) Pre-register all redirect URIs (whitelist only). (3) HTTPS mandatory for production (except http://localhost for development). (4) No wildcards () allowed (e.g., https://.example.com forbidden). (5) No open redirects (verify redirect_uri parameter matches registered exactly). Attacks prevented: authorization code interception, token theft via malicious redirects. Configuration examples: Web: https://app.example.com/callback, Mobile: myapp://callback (custom scheme) or https://app.example.com/mobile (universal links preferred). Localhost: http://localhost:3000/callback or http://127.0.0.1:3000/callback. Validation: if (redirect_uri !== registeredURIs.find(u => u === redirect_uri)) throw error. Essential OAuth security control.

OAuth 2.0 vs OAuth 1.0 (RFC 6749 vs RFC 5849): OAuth 2.0 (current standard): bearer tokens (Authorization: Bearer ), HTTPS mandatory for security, no cryptographic signatures required, multiple grant types (authorization code, client credentials, device flow), JSON responses, clearer role separation, extensible architecture. OAuth 1.0 (deprecated): request signatures using HMAC-SHA1 (complex), works without HTTPS (signatures provide integrity), single flow only, harder to implement. Benefits of 2.0: simpler implementation (no signature complexity), better mobile/SPA/IoT support, modular grant types, wider adoption. Security trade-offs: OAuth 1.0 signatures protect without HTTPS; OAuth 2.0 simpler but requires HTTPS (bearer tokens vulnerable if intercepted). Migration: OAuth 1.0 fully deprecated, all new implementations use OAuth 2.0. Current state: OAuth 1.0 only in legacy systems (old Twitter API v1), OAuth 2.0 universal industry standard. OAuth 2.1 further modernizes 2.0 with mandatory PKCE. Understanding explains protocol evolution toward simplicity and HTTPS-everywhere.

OpenID Connect (OIDC): identity authentication layer built on OAuth 2.0, provides user authentication while OAuth handles authorization (OpenID Connect Core 1.0, ISO/IEC 26131:2024). Key difference: OAuth answers 'what can you access?', OIDC answers 'who are you?'. Token additions: (1) ID Token: JWT with user claims (sub=user ID, name, email, iat, exp, iss, aud). (2) UserInfo endpoint: GET /userinfo returns additional profile claims. Flow: Authorization Code with scope=openid → returns access_token + id_token. Standard scopes: openid (required for OIDC), profile (name, picture, etc.), email, address, phone. ID token validation: verify signature, iss (issuer), aud (client_id), exp (not expired), nonce (CSRF protection). Use cases: SSO (enterprise), social login (Sign in with Google/GitHub), authentication for SPAs. Providers: Auth0, Okta, Azure AD, Google, GitHub. Example: scope='openid profile email' returns ID token with sub, name, email claims. OIDC = authentication, OAuth 2.0 = authorization. Essential for identity verification.

JWT (JSON Web Token, RFC 7519): compact, URL-safe token format for representing claims, commonly used for OAuth access tokens and OIDC ID tokens. Structure: header.payload.signature (three Base64URL-encoded parts). Header: {"alg":"RS256","typ":"JWT"}. Payload: claims (sub=user ID, exp=expiration, iat=issued at, iss=issuer, aud=audience, scope=permissions). Signature: HMAC or RSA signature for integrity verification. Validation (RFC 8725 2025): (1) Verify signature using public key/secret. (2) Check algorithm claim against allowlist (prevent 'none' attack). (3) Validate exp (not expired), nbf (not before). (4) Verify iss matches trusted issuer. (5) Verify aud matches expected audience (client_id). (6) Check jti (JWT ID) for replay prevention. Algorithms: RS256/ES256 (asymmetric, preferred), EdDSA (newest, quantum-resistant). Security: JWTs are base64-decoded (readable), don't store secrets. Expiration: 15 min for access tokens, 1 hour for ID tokens. Use for: self-contained access tokens, OIDC ID tokens. Alternative: opaque tokens (reference tokens with introspection). Essential OAuth token format.

OAuth 2.0 security best practices (RFC 9700, Jan 2025): (1) 'Always use HTTPS' for all endpoints and redirects (prevents MITM). (2) PKCE mandatory for all clients using Authorization Code (public and confidential). (3) 'Clients MUST use state parameter' for CSRF protection in authorization requests. (4) 'Authorization servers MUST use exact string matching' for redirect URI validation (no wildcards). (5) Short-lived access tokens (15-60 min, Okta 2025: 15 min standard). (6) Refresh token rotation with automatic reuse detection (invalidate token family on reuse). (7) 'Implicit grant MUST NOT be used' (removed in OAuth 2.1). (8) Validate tokens on every request: signature, exp, iss, aud, scope. (9) Granular scopes following least privilege. (10) Never store tokens in localStorage (XSS risk), use httpOnly cookies or in-memory. (11) DPoP (RFC 9449) for sender-constrained tokens (prevents token replay). (12) Implement /revoke endpoint for token revocation. (13) Rate limiting on token endpoints. (14) Audit logging for security events. (15) Regular security reviews and penetration testing. Following prevents authorization code interception, CSRF, token theft, and replay attacks.

Common OAuth 2.0 vulnerabilities (RFC 9700): (1) Authorization code interception: attacker steals code from redirect URL (mitigate: PKCE mandatory, 100% prevention). (2) CSRF attacks: attacker tricks user into authorizing attacker's linkage (mitigate: state parameter validation). (3) Open redirect: malicious redirect_uri bypasses validation (mitigate: exact string matching, no wildcards). (4) Token leakage: tokens exposed in browser history, referer headers, logs (mitigate: short expiration 15-60 min, HTTPS only, httpOnly cookies). (5) Insufficient redirect URI validation: partial matching allows attacker domains (mitigate: whitelist with exact matching). (6) Token replay: stolen token reused by attacker (mitigate: DPoP sender-constraint, short lifetime). (7) XSS token theft: JavaScript accesses localStorage tokens (mitigate: never use localStorage, httpOnly cookies, CSP headers). (8) Phishing: fake authorization page captures credentials (mitigate: user education, system browser on mobile). (9) Mix-up attacks: client confused about which authorization server issued token (mitigate: validate iss claim). Understanding enables secure implementation following RFC 9700 best practices.

SSO (Single Sign-On) with OIDC: user authenticates once to identity provider (IdP), accesses multiple applications without re-authentication. Flow: (1) User visits App A, clicks 'Sign in'. (2) App A redirects to IdP /authorize endpoint. (3) User authenticates to IdP (username/password, MFA, passkey). (4) IdP creates SSO session (httpOnly cookie, 8-hour lifetime). (5) IdP redirects to App A with authorization code. (6) App A exchanges code for access_token + id_token. (7) User visits App B, redirects to same IdP. (8) IdP recognizes active SSO session (no re-authentication). (9) IdP issues new authorization code for App B. (10) App B gets tokens, user logged in. Session management: prompt=none for silent authentication check, prompt=login to force re-authentication. Logout: RP-initiated logout (end_session_endpoint) or front-channel/back-channel logout. Protocols: OIDC (modern), SAML (legacy enterprise). IdPs: Okta, Auth0, Azure AD, Google Workspace. Use for: enterprise SaaS, multi-application environments. Essential for unified user experience.

Secure token storage by client type (Okta 2025): (1) Web apps (server-side): encrypted database, secrets manager (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault), server-side sessions. Never client-side. (2) SPAs: BFF (Backend-For-Frontend) pattern with httpOnly cookies (best) or in-memory storage (lost on refresh). NEVER localStorage/sessionStorage (XSS steals tokens). (3) Mobile apps: iOS Keychain (secure enclave), Android Keystore (hardware-backed), encrypted SharedPreferences. (4) Desktop apps: OS credential store (Windows Credential Manager, macOS Keychain). 'Refresh tokens should not be stored client-side; only securely in backend.' Cookie attributes for web: httpOnly (no JavaScript access), Secure (HTTPS only), SameSite=Strict (CSRF protection), short Max-Age. Access tokens: in-memory or short-lived cookies. Best practices: (1) Encrypt at rest (AES-256). (2) Never log tokens (redact in logs). (3) Clear on logout. (4) Use secrets rotation. (5) DPoP binding for additional security. Storage anti-patterns: localStorage, sessionStorage, unencrypted databases, query parameters. Essential security control.

Mobile OAuth security (RFC 8252, RFC 9700): (1) Authorization Code flow + PKCE mandatory for native apps. (2) System browser required (NOT embedded WebView): iOS ASWebAuthenticationSession (iOS 12+), Android Chrome Custom Tabs. Benefits: user can verify authorization page, shared cookies, more secure than WebView. (3) Redirect URI: Custom URL schemes (myapp://callback) or universal/app links (https://app.example.com/callback, preferred). Register scheme in app manifest. (4) Token storage: iOS Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly, Android Keystore (hardware-backed), encrypt refresh tokens. (5) No client_secret (public client, app is decompilable). (6) Token lifetime: access tokens 60 min, refresh token rotation enabled. (7) Biometric re-authentication for sensitive operations. (8) Certificate pinning for API calls (prevent MITM). RFC 9700: 'Public clients like native apps MUST use PKCE.' Anti-patterns: embedded WebView (phishing risk), storing secrets in app, using Implicit flow. Example redirect: myapp://callback?code=abc&state=xyz. Essential for mobile security.

SPA OAuth security (RFC 9700): (1) Authorization Code flow + PKCE mandatory (NOT Implicit flow). (2) Token storage options: BFF (Backend-For-Frontend) pattern with httpOnly cookies (most secure) or in-memory storage (lost on page refresh). NEVER localStorage (XSS risk). (3) BFF pattern: SPA calls backend proxy → backend exchanges code for tokens → backend stores tokens server-side → backend issues httpOnly session cookie to SPA. Benefits: tokens never exposed to JavaScript. (4) No client_secret (public client, JavaScript is readable). (5) Silent authentication: hidden iframe with prompt=none or refresh token via BFF. (6) Security headers: Content-Security-Policy: default-src 'self' (XSS protection), X-Frame-Options: DENY. (7) CORS configured on resource server (Access-Control-Allow-Origin). (8) Short token lifetime (15 min access tokens). (9) State parameter for CSRF. RFC 9700: 'Browser-based apps MUST use PKCE.' Modern recommendation: PKCE + BFF + httpOnly cookies. Example: fetch('/api/auth/login') → backend handles OAuth → returns session cookie. Essential SPA security pattern.

Token introspection (RFC 7662): method for resource server to query authorization server about access token's current state and metadata. Endpoint: POST /introspect with token parameter + optional token_type_hint. Response: {"active": true, "scope": "read write", "client_id": "client123", "username": "user", "exp": 1735689600, "iat": 1735686000, "sub": "user-id"}. Use cases: (1) Opaque tokens (reference tokens): resource server cannot decode token locally, must introspect for metadata. (2) Real-time revocation checking: verify token not revoked even if JWT (JWTs are self-contained but revocation requires server check). (3) Multi-tenant validation: verify token belongs to correct tenant/organization. (4) Additional claims: retrieve user info, roles, permissions not in token. Authentication: resource server authenticates to introspection endpoint with client credentials. Performance: adds network latency on every API request. Optimization: cache introspection results for token's remaining lifetime (check exp - iat). JWT vs opaque: JWT allows local validation (no introspection), opaque requires introspection. Use introspection for: opaque tokens, revocation checking, server-side validation. Essential for opaque token architectures.

Token revocation (RFC 7009): mechanism for clients to notify authorization server that token should no longer be valid. Endpoint: POST /revoke with token parameter + optional token_type_hint (access_token or refresh_token). Request: client authenticates with client_id + client_secret, sends token to revoke. Response: HTTP 200 (success) or appropriate error. Revocable: access tokens, refresh tokens. Behavior: revoking refresh token should revoke all associated access tokens (token family). Use cases: (1) User logout: revoke all user's tokens. (2) Security incident: immediately invalidate compromised token. (3) Permission changes: revoke and reissue with new scopes. (4) Account suspension: revoke all user tokens. JWT limitations: self-contained JWTs cannot be revoked without server-side deny-list or requiring introspection on every request. Opaque tokens: easily revocable (database lookup). Best practices: (1) Implement /revoke endpoint. (2) Short-lived access tokens (15-60 min reduces revocation urgency). (3) Revoke refresh tokens on logout. (4) Cascade revocation (refresh token → all access tokens). (5) Audit log all revocations. (6) Rate limit revocation endpoint. Token family revocation critical for refresh token rotation security. Essential for security compliance.

Resource Owner Password Credentials (ROPC) flow: client directly collects and sends user's username + password to authorization server for access token (RFC 6749). Flow: POST /token with grant_type=password&username=user&password=pass&client_id=...&scope=... → receives access_token. Why deprecated: (1) Client sees user credentials (violates OAuth delegation principle). (2) Credentials directly exposed to client (phishing risk). (3) No MFA/2FA support (bypasses security). (4) No user consent screen (no transparency). (5) Difficult to revoke per-app access (all-or-nothing). (6) Stores passwords in client (security risk). (7) Cannot use SSO/federated identity. OAuth 2.1 removes ROPC entirely. When previously acceptable: highly-trusted first-party apps (same organization), legacy migration only. Modern alternatives: Authorization Code + PKCE (redirect-based), Device Authorization Grant (RFC 8628) for input-constrained devices. Migration path: replace ROPC with Authorization Code + PKCE, implement redirect flow. Best practice: never use ROPC for new applications, migrate away immediately. Security note: ROPC contradicts OAuth's core security model. Understanding explains OAuth anti-patterns.

OAuth consent screen: UI shown during authorization where user grants/denies requested permissions to client application (RFC 6749). Components displayed: (1) Client identification: app name, logo, publisher/developer name, verified badge (if applicable). (2) Scope descriptions: user-friendly explanation of each requested permission (e.g., 'read:email' → 'View your email address'). (3) Account selection: which user account to authorize. (4) Consent buttons: 'Allow' and 'Deny'. Google 2025 best practices: (1) 'Use incremental authorization to request appropriate OAuth scopes when functionality needed' (request scopes progressively, not all upfront). (2) Granular scope descriptions in plain language. (3) Highlight sensitive/dangerous scopes (access to private data, write permissions). (4) Allow partial consent (user can uncheck specific scopes). (5) Remember consent (prompt_consent=false for returning users). (6) Easy revocation via user account settings. (7) Show data access frequency/last access. Implementation: authorization server renders consent screen at /authorize endpoint. Branding: customize app name, logo, privacy policy link. User experience: minimal friction, clear security indicators. Regulatory: GDPR requires explicit, informed consent. Consent storage: record user consent decisions with timestamp, scope list. Withdrawal: implement consent revocation endpoint. Essential for user trust, security transparency, and legal compliance.

Implicit flow returns access token directly in URL fragment, creating severe security vulnerabilities. Problems: (1) Access tokens exposed in browser history and referer headers. (2) No refresh tokens (security limitation). (3) No client authentication. (4) Vulnerable to XSS attacks (JavaScript can access token). (5) Authorization Code + PKCE provides same UX with better security. RFC 9700 (Jan 2025): 'Implicit grant MUST NOT be used.' OAuth 2.1 removes Implicit entirely. Migration: use Authorization Code + PKCE for SPAs (same redirect flow, more secure) or BFF pattern with httpOnly cookies. Legacy apps must migrate immediately - major security risk. Never use for new applications. Understanding explains OAuth security evolution.

Access token is credential for accessing protected resources, representing authorization issued to client (RFC 6749). Format: JWT (self-contained with claims) or opaque reference token (requires introspection). JWT payload contains: sub (user ID), scope, exp (expiration), iss (issuer), aud (audience). Usage: Authorization: Bearer header. Lifetime: 15-60 minutes recommended (Okta 2025: 15 min). Security: (1) HTTPS mandatory. (2) Short expiration limits blast radius. (3) Use DPoP for sender-constraint (RFC 9449, prevents replay). (4) Never store in localStorage (XSS risk). (5) Validate signature, exp, iss, aud on every request. Storage: in-memory (SPAs), httpOnly cookie with BFF, server-side encrypted. Essential OAuth credential.

Refresh token is long-lived credential for obtaining new access tokens without re-authentication (RFC 6749). Flow: POST /token with grant_type=refresh_token → receives new access_token + new refresh_token (if rotation enabled). Refresh Token Rotation (Auth0 2025): every refresh returns new token and invalidates previous. If reused token detected: revoke entire token family. Lifetime: 7 days typical, absolute expiration at creation. Security: (1) Store server-side only. (2) One-time use with rotation prevents replay. (3) Bind to client_id. (4) Revocable via /revoke. (5) Use shortest reuse interval. Use for: SPAs with BFF, mobile apps, long-lived sessions. Enable with offline_access scope. Rotation makes refresh tokens acceptable for SPAs.

Scopes are space-delimited permissions limiting access token privileges (RFC 6749). Format: scope='openid profile email read:orders write:cart'. Naming: action:resource (read:email, write:profile, admin:users). Google 2025 best practices: (1) Use incremental authorization - request scopes when functionality needed (not all upfront). (2) Make scopes as granular as possible to prevent excessive permissions. (3) Document each scope purpose clearly. Validation: resource server must validate token scopes match required permissions. Standard OIDC scopes: openid (required), profile, email, address, phone. Custom scopes: api:read, api:write, admin:all. Never grant more than requested (no scope upgrade). Use for: API authorization, user consent, audit logging. Essential security control.

State parameter provides CSRF protection for OAuth authorization requests (RFC 6749, RFC 9700). Flow: (1) Client generates random state (minimum 128 bits, use crypto.randomBytes(32).toString('hex')). (2) Stores state in session/cookie. (3) Includes state in /authorize request. (4) Server returns unchanged state in callback. (5) Client validates returned state matches stored value exactly. Attack prevented: CSRF where attacker tricks victim into authorizing attacker's account linkage. RFC 9700 (Jan 2025): 'Clients MUST use state parameter for CSRF protection.' Implementation: const state = crypto.randomUUID(); store in httpOnly cookie with SameSite=Lax. Never reuse state values. Combine with PKCE for defense-in-depth. Essential security parameter.

Redirect URI is where authorization server sends user with code/tokens after authorization (RFC 6749). RFC 9700 (Jan 2025) requirements: (1) 'Authorization servers MUST use exact string matching' for redirect URIs (no substring/pattern matching). (2) Pre-register all URIs (whitelist only). (3) HTTPS mandatory for production (except http://localhost for dev). (4) No wildcards (https://*.example.com forbidden). (5) No open redirects. Attacks prevented: code interception, token theft via malicious redirects. Examples: Web https://app.example.com/callback, Mobile myapp://callback or https://app.example.com/mobile (universal links preferred), Localhost http://localhost:3000/callback. Validation: exact match only. Essential security control.

OpenID Connect (OIDC) is identity authentication layer built on OAuth 2.0 (OpenID Connect Core 1.0, ISO/IEC 26131:2024). Key difference: OAuth answers 'what can you access?', OIDC answers 'who are you?'. Token additions: (1) ID Token - JWT with user claims (sub, name, email, iat, exp, iss, aud). (2) UserInfo endpoint - GET /userinfo returns profile claims. Flow: Authorization Code with scope=openid → returns access_token + id_token. Standard scopes: openid (required), profile, email, address, phone. ID token validation: verify signature, iss, aud (client_id), exp, nonce. Use cases: SSO, social login (Sign in with Google/GitHub), SPA authentication. Providers: Auth0, Okta, Azure AD, Google. OIDC = authentication, OAuth = authorization.

OAuth 2.0 security best practices (RFC 9700, Jan 2025): (1) Always use HTTPS for all endpoints. (2) PKCE mandatory for all Authorization Code flows. (3) State parameter required for CSRF protection. (4) Exact string matching for redirect URI validation (no wildcards). (5) Short-lived access tokens (15-60 min, Okta: 15 min standard). (6) Refresh token rotation with reuse detection. (7) Never use Implicit grant (removed in OAuth 2.1). (8) Validate tokens on every request: signature, exp, iss, aud, scope. (9) Granular scopes following least privilege. (10) Never store tokens in localStorage (XSS risk), use httpOnly cookies. (11) DPoP (RFC 9449) for sender-constrained tokens. (12) Implement /revoke endpoint. (13) Rate limiting on token endpoints. Following prevents code interception, CSRF, token theft, replay attacks.