Authentication answers the question “who is this actor?” before the system decides what that actor is allowed to do. Passwords alone are insufficient — they are phished, stuffed from breach databases, guessed, and shared. Strong authentication raises the bar by requiring a second independent factor (something the user has or is) or by using a protocol that is inherently resistant to phishing (FIDO2/WebAuthn, mutual TLS).

Centralizing authentication through an OIDC-compliant identity provider (IdP) gives every application in the ecosystem a consistent, auditable identity signal without each application implementing its own credential storage and verification logic. The IdP issues short-lived, signed tokens (JWTs) that downstream services can verify independently, decoupling identity verification from session management.

How It Works

  • Centralize user authentication through an OIDC-compliant identity provider that handles credential verification, MFA enforcement, and token issuance.
  • Require at least two independent factors for all privileged access: password + TOTP, password + push notification, or (preferred) FIDO2/WebAuthn hardware key.
  • Issue short-lived, signed tokens (access tokens, ID tokens) with defined scopes and audience claims; services verify tokens locally using the IdP’s published signing keys (JWKS).
  • Enforce re-authentication for sensitive operations (privilege escalation, financial transactions, security setting changes) even within an active session.
  • For service-to-service authentication, use mutual TLS or OAuth 2.0 client credentials with Secret Management-issued client secrets and short-lived tokens.
  • Monitor authentication events: failed logins, MFA bypasses, token-refresh anomalies, and geographic or device changes — feed these into intrusion detection.
  • Least Privilege takes over after authentication: the verified identity determines what the actor can access.

Failure Modes

  • MFA fatigue: attackers bombard a user with push notifications until the user approves one out of frustration — mitigated by number-matching or FIDO2.
  • Fallback to password-only: MFA is configured but a “skip for now” or “remember this device for 90 days” escape hatch weakens the second factor.
  • Token lifetime too long: access tokens that live for hours or days reduce the value of token revocation and increase the window for stolen-token abuse.
  • Identity provider outage: if the IdP is unreachable, all authentication fails; cached tokens may continue to work but new logins are impossible.
  • Service-to-service authentication using long-lived shared secrets instead of short-lived tokens — equivalent to a shared password with no rotation.

Verification

  • Phishing simulation: send a credential-harvesting page to test users and verify that FIDO2/WebAuthn users cannot be phished (the authenticator will not respond to a different origin).
  • MFA enforcement: attempt login to privileged resources with valid password only and verify that access is denied until the second factor is provided.
  • Token lifetime: inspect issued tokens and verify that access-token lifetime does not exceed the defined maximum (for example 15 min for access tokens, 8 h for refresh tokens).
  • Brute-force resistance: send 100 failed login attempts for a single account and verify that rate limiting or account lockout engages within the configured threshold (for example after 5 attempts).
  • IdP failover: simulate IdP unavailability and verify that existing sessions remain valid (cached token verification) while new logins fail fast with a clear error.
  • FIDO2/WebAuthn eliminates passwords entirely — the authenticator (hardware key or platform biometric) performs a challenge-response that is bound to the origin, making phishing structurally impossible.
  • Mutual TLS (mTLS) provides certificate-based authentication for service-to-service communication, combining identity verification with Encryption at Rest + in Transit.
  • Step-up authentication dynamically requires a stronger factor for high-risk operations based on transaction risk scoring.
  • Least Privilege depends on strong authentication: permissions are only meaningful when the identity claiming them is verified.
  • Secret Management stores and rotates the OIDC client secrets, signing keys, and mTLS certificates that the authentication infrastructure depends on.
  • Input Sanitization / Output Encoding prevents XSS-based session theft that could bypass even strong authentication.

References