{"data":{"id":"SP-032","slug":"modern-authentication","title":"Modern Authentication","description":"Enterprise authentication architecture pattern covering directory services, federation, and token-based authentication using OIDC, OAuth 2.0, and JWT. Provides a worked example of end-to-end authentication flow from user login through token issuance, validation, and session management. Maps 42 NIST 800-53 controls across identity, access, and cryptographic domains.","url":"https://www.opensecurityarchitecture.org/patterns/sp-032","metadata":{"release":"26.02","classification":"Identity and Access Management","status":"active","type":"pattern","datePublished":"2026-02-07","dateModified":"2026-02-07","authors":["Aurelius","Vitruvius"],"reviewers":[],"provenance":"Derived from implementing enterprise authentication across financial services, where legacy LDAP/Kerberos environments were migrated to modern OIDC/OAuth 2.0 federation. Informed by deploying identity platforms serving millions of users with strict regulatory requirements for authentication strength, session management, and audit trails."},"diagram":{"svg":"/images/sp-032-modern-authentication.svg","png":""},"content":{"description":"Modern Authentication replaces the patchwork of proprietary authentication mechanisms that accumulated over decades with a coherent, standards-based architecture. At its core, the pattern separates the concerns of identity assertion (who are you?), authentication (prove it), authorisation (what can you access?), and session management (how long does that proof last?) into distinct, interoperable components.\n\nThe architecture centres on an Identity Provider (IdP) that serves as the single source of authentication truth. Users authenticate once against the IdP using strong credentials, and the IdP issues cryptographically signed tokens that downstream applications and APIs validate independently. This eliminates the anti-pattern of every application maintaining its own user database and password store.\n\nThree protocols form the foundation. OpenID Connect (OIDC) provides identity assertion on top of OAuth 2.0, giving applications a standardised way to verify user identity and receive basic profile claims. OAuth 2.0 handles delegated authorisation, allowing users to grant applications scoped access to resources without sharing credentials. JSON Web Tokens (JWT) provide the token format: self-contained, signed, optionally encrypted, and verifiable without calling back to the issuer.\n\nA worked example illustrates the complete flow. A user accesses a web application. The application redirects to the corporate IdP. The IdP challenges with MFA (something the user knows plus a FIDO2 security key). On success, the IdP issues an ID token (identity claims), an access token (authorisation claims with scoped permissions), and a refresh token (for session continuation without re-authentication). The application validates the ID token signature, extracts claims, creates a local session, and uses the access token to call backend APIs. Each API validates the access token independently, checks scopes and expiry, and enforces authorisation. When the access token expires, the application uses the refresh token to obtain a new one without interrupting the user. When the refresh token expires or is revoked, the user must re-authenticate.\n\nThis pattern applies whether your directory is Azure AD, Okta, on-premises Active Directory with ADFS federation, or any OIDC-compliant provider. The principles are protocol-level, not vendor-specific.","keyControlAreas":["Identity Provider and Directory Services (IA-02, IA-04, IA-05, IA-08, IA-12, AC-02): The Identity Provider is the trust anchor. IA-02 mandates identification and authentication for all organisational users, implemented through the IdP as the single authentication gateway. IA-04 governs identifier management: user identifiers must be unique, non-reusable, and tied to verified identities through lifecycle management (provisioning from HR systems, automatic deprovisioning on termination). IA-05 controls authenticator management: password policies (length, complexity, breach-list checking), MFA token lifecycle, certificate management, and FIDO2 credential registration. IA-08 extends authentication to non-organisational users through federation: partners, contractors, and customers authenticate against their own IdPs with trust established through metadata exchange and certificate pinning. IA-12 provides identity proofing for initial enrollment: verifying that the person requesting an account is who they claim to be, using a combination of document verification, knowledge-based verification, and in-person or video proofing. AC-02 manages the account lifecycle: joiner-mover-leaver processes automated through SCIM provisioning from HR systems to the IdP and downstream applications.","Token Architecture and Cryptographic Security (SC-12, SC-13, SC-23, SC-08, IA-09): Tokens are the currency of modern authentication and must be cryptographically sound. SC-12 governs cryptographic key establishment and management for token signing: RSA or ECDSA key pairs for JWT signatures, key rotation schedules, and secure key storage in HSMs or cloud KMS. SC-13 mandates approved cryptographic mechanisms: RS256/ES256 for token signatures, AES-256 for token encryption (JWE) when tokens contain sensitive claims. SC-23 ensures session authenticity through token validation: signature verification, issuer validation, audience restriction, expiry checking, and nonce verification to prevent replay. SC-08 protects tokens in transit with TLS 1.2+ for all authentication flows -- tokens must never traverse unencrypted channels. IA-09 provides service identification and authentication: API-to-API authentication using client credentials flow with signed JWTs (private_key_jwt), eliminating shared secrets between services. Implementation must address token storage: access tokens in memory only (never localStorage for SPAs), refresh tokens in secure HTTP-only cookies or backend session stores, and ID tokens validated then discarded.","OAuth 2.0 Flows and Authorisation (AC-03, AC-06, AC-17, AC-21, AC-01): OAuth 2.0 provides granular, delegated authorisation. AC-03 enforces access based on token scopes and claims rather than network position. AC-06 implements least privilege through minimal scope grants: applications request only the scopes they need, and the IdP enforces scope consent. AC-17 governs remote access: OAuth 2.0 replaces VPN-based application access with token-based authorisation that works identically for on-premises and remote users. AC-21 enables controlled information sharing: OAuth scopes define precisely what data can be accessed and shared between systems. AC-01 defines the access control policy that governs scope definitions, consent requirements, and token lifetime policies. The pattern mandates specific flows for specific contexts: authorisation code flow with PKCE for web and mobile applications (never the implicit flow), client credentials flow for service-to-service communication, device authorisation flow for IoT and constrained devices. The deprecated resource owner password credentials flow must not be used -- it requires the application to handle user credentials directly, defeating the purpose of the IdP.","Session Management and Token Lifecycle (AC-12, AC-07, IA-11, SC-23): Sessions must be managed securely across their lifecycle. AC-12 governs session termination: idle timeout (15 minutes for sensitive applications), absolute timeout (8-12 hours for standard applications), and forced termination on security events (password change, MFA reset, risk signal). AC-07 limits unsuccessful authentication attempts: account lockout or progressive delay after repeated failures, with lockout events fed to the monitoring pipeline. IA-11 provides re-authentication: step-up authentication when accessing sensitive resources within an active session, triggered by risk signals or resource sensitivity. SC-23 ensures session tokens cannot be forged, replayed, or hijacked. Token lifetimes must be appropriate: access tokens short-lived (5-15 minutes), refresh tokens longer (hours to days depending on risk), ID tokens single-use for authentication. Refresh token rotation (one-time use with automatic reissuance) prevents token theft from granting persistent access. Global sign-out must propagate across all relying parties through back-channel logout or token revocation.","Federation and Multi-Domain Trust (IA-08, IA-04, SC-12, AC-03, SA-09): Federation enables authentication across organisational boundaries without credential sharing. IA-08 provides the control basis for non-organisational user authentication through federated IdPs: SAML 2.0 for legacy enterprise federation, OIDC for modern web-based federation. IA-04 manages federated identifiers: mapping external identities to internal representations, handling name collisions, and maintaining the binding between federated and local accounts. SC-12 establishes the cryptographic trust: metadata exchange, certificate validation, and trust anchor management for federated IdPs. AC-03 enforces access policies that account for federation context: claims from external IdPs may be mapped to different privilege levels than internal authentication. SA-09 governs the external services (federated IdPs) that the organisation depends on: ensuring SLAs, security requirements, and incident notification obligations are contractually defined. Trust must be explicitly configured per federation partner -- never configure wildcard or open federation.","Audit, Compliance, and Monitoring (AU-02, AU-03, AU-06, AU-12, CA-07): Every authentication event must be auditable. AU-02 defines auditable events: successful and failed authentications, MFA challenges and results, token issuance and revocation, session creation and termination, consent grants, account lifecycle events, and administrative actions on the IdP. AU-03 specifies record content: user identifier, source IP, device fingerprint, authentication method used, result, timestamp, and relying party. AU-06 mandates analysis: detecting brute force attacks, credential stuffing, anomalous authentication patterns (impossible travel, unusual hours, new devices), and token abuse. AU-12 ensures audit records are generated at the IdP, at relying parties during token validation, and at APIs during access token verification. CA-07 provides continuous monitoring of the authentication infrastructure: IdP availability, certificate expiry, key rotation compliance, and detection of authentication anomalies.","Migration from Legacy Authentication (IA-02, IA-05, PL-02, CM-03, SA-08): Most organisations are migrating, not building greenfield. IA-02 must be maintained throughout migration: dual authentication paths (legacy and modern) during transition, with controls to prevent regression to weaker mechanisms. IA-05 manages authenticator migration: LDAP passwords may need to be re-established through verified password reset rather than migration of password hashes (which may use deprecated algorithms). PL-02 documents the migration plan including interim architectures, rollback procedures, and acceptance criteria for each migration phase. CM-03 controls configuration changes during migration: IdP configuration is infrastructure-as-code, version-controlled, and peer-reviewed. SA-08 applies security engineering principles: fail-closed design (if the IdP is unreachable, deny access rather than bypass authentication), defence in depth (validate tokens at every layer, not just the edge), and minimal trust (verify every claim, trust no input)."],"assumptions":"The organisation has or will deploy an OIDC-compliant Identity Provider (Azure AD, Okta, Auth0, Keycloak, or similar). Applications can be modified or configured to support OIDC/OAuth 2.0 authentication (either natively or through reverse proxy/gateway). Network connectivity exists between applications and the IdP with acceptable latency for authentication flows. A directory service (Active Directory, LDAP, or cloud directory) exists as the authoritative user store. The organisation has defined authentication strength requirements per application or data classification. PKI or KMS capability exists for managing token signing keys.","typicalChallenges":"Legacy applications that only support LDAP bind or NTLM authentication cannot directly consume OIDC tokens and require authentication proxies or gateway translation layers, adding latency and complexity. Migrating from per-application password databases to centralised IdP requires coordinated password resets and user communication. JWT token size grows with claims and can exceed HTTP header limits in complex authorisation scenarios, requiring claims filtering or reference tokens. Refresh token security is frequently misunderstood: storing refresh tokens in browser localStorage is a common vulnerability that enables persistent account takeover through XSS. Session management across multiple single-page applications sharing an IdP creates complex logout propagation challenges. Service-to-service authentication with client credentials generates long-lived tokens that, if leaked, provide persistent access -- short token lifetimes and certificate-bound tokens mitigate this but add operational complexity. Multi-cloud environments may require multiple IdP instances or complex federation topologies. Developers frequently implement OAuth 2.0 incorrectly: skipping state parameter validation (CSRF), using the implicit flow for SPAs, or failing to validate token signatures.","indications":"This pattern applies to any organisation that authenticates users to applications -- effectively universal. It is particularly relevant when: multiple applications maintain separate user databases and password stores (authentication sprawl), the organisation is adopting cloud services and needs SSO across on-premises and cloud, regulatory requirements mandate strong authentication and comprehensive audit trails, the organisation needs to provide authenticated access to external parties (customers, partners, contractors), mobile and API-first architectures require token-based authentication, or the organisation is moving to zero trust and needs identity as the primary security boundary.","contraIndications":"Organisations with a single monolithic application and no integration requirements may find the overhead of deploying an IdP and implementing OIDC disproportionate -- though even here, modern authentication provides future-proofing. Environments where all applications are air-gapped and users are authenticated purely through physical access controls have different authentication requirements. Industrial control systems and embedded devices that cannot support HTTP-based authentication flows require specialised protocols (see SP-023).","threatResistance":"Modern Authentication addresses the majority of credential-based attack vectors. Password spraying and credential stuffing are mitigated by centralised authentication with rate limiting, account lockout, and breach-list checking (IA-05, AC-07). Phishing attacks that steal passwords are neutralised when MFA is enforced (IA-02), and fully eliminated when phishing-resistant methods like FIDO2 are used (see SP-033). Token theft is mitigated by short token lifetimes, token binding, refresh token rotation, and secure storage practices (SC-23, AC-12). Session hijacking is addressed through token signature validation, audience restriction, and TLS for all token-bearing requests (SC-08, SC-23). Cross-site request forgery is prevented by OAuth 2.0 state parameter and PKCE (AC-03). Man-in-the-middle attacks on authentication flows are prevented by TLS and token signature validation (SC-08, SC-12). Privilege escalation through token manipulation is prevented by cryptographic signatures that make token tampering detectable (SC-13). Replay attacks are prevented by nonce validation, token expiry, and one-time-use constraints (SC-23). Identity impersonation is mitigated by identity proofing and MFA (IA-12, IA-02)."},"examples":{"Web Application Authentication (Authorization Code + PKCE)":["User clicks 'Sign In' -> app redirects to IdP /authorize endpoint with code_challenge (PKCE), state, and requested scopes","IdP authenticates user with password + FIDO2 key, issues authorization code, redirects back to app","App exchanges code + code_verifier for tokens at IdP /token endpoint (back-channel, never exposed to browser)","App validates ID token signature (RS256), extracts sub/email/groups claims, creates encrypted server-side session"],"API Authentication (Client Credentials + JWT Bearer)":["Payment service authenticates to fraud detection API using client_credentials grant with private_key_jwt assertion","IdP validates client certificate, issues access token with scope 'fraud:check' and 5-minute expiry","Fraud API validates token: checks signature, issuer, audience, expiry, and scope before processing request","Token cached for remaining lifetime, new token requested automatically before expiry using token endpoint"],"Federation (B2B Partner Access)":["Partner organisation registers as federated IdP: metadata exchange, certificate pinning, scope restrictions","Partner user authenticates at their own IdP, receives OIDC token with partner-specific claims","Our application validates partner IdP token, maps claims to local roles (partner:read, partner:submit), creates scoped session","Access restricted to partner-specific resources; all actions audited with federated identity context"],"Migration from Legacy (LDAP to OIDC)":["Phase 1: Deploy OIDC IdP with LDAP backend -- existing passwords work, users see new login page, apps unchanged","Phase 2: Integrate first wave of applications with OIDC, LDAP proxy translates for legacy apps concurrently","Phase 3: Enable MFA at IdP layer -- all applications get MFA automatically without individual changes","Phase 4: Migrate remaining legacy apps, decommission LDAP proxy, enforce OIDC-only authentication"],"Developing Areas":["Passkey adoption is displacing passwords faster than enterprise infrastructure can adapt. Consumer platforms report passkey registration rates of 30-40% among eligible users, but enterprise IdPs lag behind with single-digit adoption due to legacy application compatibility and policy inertia around password-based fallback paths.","Identity federation attacks -- particularly token theft and session hijacking via adversary-in-the-middle proxies like Evilginx -- are evolving faster than defensive controls. Token binding (DPoP) and continuous access evaluation are emerging as countermeasures, but fewer than 15% of enterprise IdP deployments have implemented either, leaving a persistent gap between phishing-resistant authentication and phishable session tokens.","Session management in single-page applications and mobile apps remains architecturally unsettled. The deprecation of third-party cookies, divergent browser storage policies, and the tension between user experience (long sessions) and security (short token lifetimes) mean that best practices shift with every major browser release. Backend-for-frontend (BFF) patterns are gaining traction but add deployment complexity.","Decentralised identity and verifiable credentials (W3C DID, ISO 18013-5 mDL) promise to eliminate centralised IdP dependency, but the ecosystem is fragmented across competing wallet implementations, trust registries, and credential schemas. Enterprise adoption remains experimental, with fewer than 2% of organisations piloting verifiable credentials for workforce authentication.","Continuous authentication -- adjusting trust levels based on real-time signals like device posture, location, and behavioural biometrics -- is conceptually compelling but practically immature. Most implementations are limited to step-up MFA triggers rather than true continuous risk scoring, and the privacy implications of persistent behavioural monitoring are unresolved in most regulatory frameworks."]},"references":[{"title":"OpenID Connect Core 1.0 Specification","url":"https://openid.net/specs/openid-connect-core-1_0.html","note":"The definitive specification for OpenID Connect. Defines ID tokens, claims, authentication flows, and session management. Required reading for any OIDC implementation."},{"title":"OAuth 2.0 Authorization Framework (RFC 6749)","url":"https://datatracker.ietf.org/doc/html/rfc6749","note":"The foundational OAuth 2.0 specification defining authorization grants, token types, and client registration. Read alongside the Security Best Current Practice (RFC 9700)."},{"title":"OAuth 2.0 Security Best Current Practice (RFC 9700)","url":"https://datatracker.ietf.org/doc/html/rfc9700","note":"Essential security guidance for OAuth 2.0 implementations. Deprecates the implicit flow, mandates PKCE for all public clients, and addresses current attack vectors."},{"title":"JSON Web Token (JWT) (RFC 7519)","url":"https://datatracker.ietf.org/doc/html/rfc7519","note":"Defines the JWT format used for ID tokens and access tokens. Covers claims, signing (JWS), and encryption (JWE)."},{"title":"NIST SP 800-63-4: Digital Identity Guidelines","url":"https://pages.nist.gov/800-63-4/","note":"Comprehensive guidance on digital identity including enrollment, authentication, and federation. Defines Identity Assurance Levels (IAL) and Authenticator Assurance Levels (AAL)."},{"title":"NIST SP 800-53 Rev 5: Security and Privacy Controls","url":"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final","note":"The control catalogue referenced throughout this pattern. IA (Identification and Authentication) and AC (Access Control) families are core."},{"title":"OAuth 2.0 for Browser-Based Applications (RFC 10017)","url":"https://datatracker.ietf.org/doc/html/rfc10017","note":"Specific guidance for single-page application authentication with OAuth 2.0 including DPoP (Demonstrating Proof of Possession)."}],"relatedPatterns":["SP-010","SP-029","SP-030","SP-033"],"relatedPatternNames":["Identity Management","Zero Trust Architecture","API Security","Passkey Authentication"],"threats":[{"id":"T-MA-001","name":"Credential stuffing using breached password databases","mitigatedBy":["IA-05","AC-07","AU-06","IA-02"]},{"id":"T-MA-002","name":"Phishing for passwords and MFA codes","mitigatedBy":["IA-02","IA-05","AT-02","IA-12"]},{"id":"T-MA-003","name":"OAuth token theft via XSS or insecure storage","mitigatedBy":["SC-23","AC-12","SC-08","SA-08"]},{"id":"T-MA-004","name":"Session hijacking through stolen session cookies","mitigatedBy":["SC-23","SC-08","AC-12","SI-04"]},{"id":"T-MA-005","name":"JWT signature bypass or algorithm confusion attack","mitigatedBy":["SC-13","SC-12","SA-08","AU-06"]},{"id":"T-MA-006","name":"Authorisation code interception (CSRF/replay)","mitigatedBy":["AC-03","SC-23","SC-08","SA-08"]},{"id":"T-MA-007","name":"Identity provider compromise or misconfiguration","mitigatedBy":["CA-07","CM-03","SC-12","AU-06"]},{"id":"T-MA-008","name":"Privilege escalation through token scope manipulation","mitigatedBy":["AC-06","AC-03","SC-13","AU-06"]},{"id":"T-MA-009","name":"Federation trust exploitation by compromised partner IdP","mitigatedBy":["IA-08","SA-09","SC-12","AC-03"]},{"id":"T-MA-010","name":"Account takeover via password reset flow abuse","mitigatedBy":["IA-05","IA-12","AU-02","AC-07"]},{"id":"T-MA-011","name":"Service-to-service credential theft (client secrets)","mitigatedBy":["IA-09","SC-12","SC-13","AU-02"]},{"id":"T-MA-012","name":"Refresh token abuse for persistent unauthorised access","mitigatedBy":["AC-12","SC-23","AU-06","IR-04"]}],"controls":[{"id":"AC-01","name":"Policy and Procedures","family":"AC","emphasis":"standard"},{"id":"AC-02","name":"Account Management","family":"AC","emphasis":"critical"},{"id":"AC-03","name":"Access Enforcement","family":"AC","emphasis":"critical"},{"id":"AC-06","name":"Least Privilege","family":"AC","emphasis":"important"},{"id":"AC-07","name":"Unsuccessful Logon Attempts","family":"AC","emphasis":"important"},{"id":"AC-08","name":"System Use Notification","family":"AC","emphasis":"standard"},{"id":"AC-12","name":"Session Termination","family":"AC","emphasis":"critical"},{"id":"AC-17","name":"Remote Access","family":"AC","emphasis":"important"},{"id":"AC-21","name":"Information Sharing","family":"AC","emphasis":"standard"},{"id":"AT-02","name":"Literacy Training and Awareness","family":"AT","emphasis":"standard"},{"id":"AU-02","name":"Event Logging","family":"AU","emphasis":"critical"},{"id":"AU-03","name":"Content of Audit Records","family":"AU","emphasis":"important"},{"id":"AU-06","name":"Audit Record Review, Analysis, and Reporting","family":"AU","emphasis":"important"},{"id":"AU-12","name":"Audit Record Generation","family":"AU","emphasis":"important"},{"id":"CA-07","name":"Continuous Monitoring","family":"CA","emphasis":"important"},{"id":"CM-03","name":"Configuration Change Control","family":"CM","emphasis":"important"},{"id":"CM-06","name":"Configuration Settings","family":"CM","emphasis":"standard"},{"id":"IA-02","name":"Identification and Authentication (Organizational Users)","family":"IA","emphasis":"critical"},{"id":"IA-04","name":"Identifier Management","family":"IA","emphasis":"critical"},{"id":"IA-05","name":"Authenticator Management","family":"IA","emphasis":"critical"},{"id":"IA-06","name":"Authentication Feedback","family":"IA","emphasis":"standard"},{"id":"IA-08","name":"Identification and Authentication (Non-organizational Users)","family":"IA","emphasis":"critical"},{"id":"IA-09","name":"Service Identification and Authentication","family":"IA","emphasis":"important"},{"id":"IA-11","name":"Re-authentication","family":"IA","emphasis":"important"},{"id":"IA-12","name":"Identity Proofing","family":"IA","emphasis":"important"},{"id":"PL-02","name":"System Security and Privacy Plans","family":"PL","emphasis":"standard"},{"id":"SA-08","name":"Security and Privacy Engineering Principles","family":"SA","emphasis":"important"},{"id":"SA-09","name":"External System Services","family":"SA","emphasis":"important"},{"id":"SC-08","name":"Transmission Confidentiality and Integrity","family":"SC","emphasis":"critical"},{"id":"SC-12","name":"Cryptographic Key Establishment and Management","family":"SC","emphasis":"critical"},{"id":"SC-13","name":"Cryptographic Protection","family":"SC","emphasis":"critical"},{"id":"SC-23","name":"Session Authenticity","family":"SC","emphasis":"critical"},{"id":"SI-04","name":"System Monitoring","family":"SI","emphasis":"important"}],"controlFamilySummary":{"AC":9,"AT":1,"AU":4,"CA":1,"CM":2,"IA":8,"PL":1,"SA":2,"SC":4,"SI":1}}}