Modern Authentication

Key Control Areas

• 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).

When to Use

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.

When NOT to Use

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).

Typical Challenges

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.

Threat Resistance

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).

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.

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.