Chapter 11: MFA and Conditional Access — Dispersing Authentication Risk

This is Part 11 of a chapter-by-chapter walkthrough of my book OpenID: Modern Identity for Developers and Architects. In the previous chapter we built out enterprise SSO. Chapter 11 addresses its weakness: concentrating every app's login into one credential makes that credential catastrophically valuable.

11.1 — MFA Fundamentals

Three factor categories: something you know (password), something you have (phone, hardware key), something you are (fingerprint, face). MFA requires at least two from different categories. That simple rule is why MFA is the single highest-ROI security control you can deploy — password compromise alone is no longer sufficient for takeover.

Chapter 11 walks through the menu: TOTP (software authenticator apps, ubiquitous, phishable), push-based approval (better UX, vulnerable to MFA-fatigue attacks), hardware security keys (FIDO2/WebAuthn, unphishable, the gold standard), and biometrics (convenient but device-bound). Each has a legitimate place; none is universally "the right answer."

11.2 — Risk-Based Authentication

Requiring MFA on every login generates fatigue — and MFA fatigue is itself an attack vector. Risk-based authentication (adaptive auth) fixes this by scoring login attempts using contextual signals: IP, geolocation, device fingerprint, time-of-day patterns, impossible-travel detection. Low-risk logins pass through quietly; high-risk logins get challenged.

The scoring is never perfect. Too aggressive, you lock out real users (and they complain up the chain). Too permissive, you miss real attacks. The chapter walks through signal selection, calibration, and how to design user-facing challenges that feel reasonable when they fire.

11.3 — Step-Up Authentication

Not every operation needs the same assurance level. Logging in to read email is not the same as transferring funds, and your application can and should ask for stronger authentication at sensitive boundaries. OpenID Connect makes this explicit through two claims: acr (Authentication Context Class Reference — a level of assurance) and amr (Authentication Methods Reference — the specific methods used).

A login with just a password might return acr: 1. Adding MFA bumps it to acr: 2. Your application reads the current session's acr, and if the user wants to perform a high-stakes action and the current assurance is insufficient, you redirect them back to the IdP with an acr_values parameter asking for a stronger authentication.

What Chapter 11 Sets Up

After Chapter 11 you should be able to map MFA methods to risk levels, reason about when adaptive MFA helps vs. annoys, and use acr and amr claims to build step-up flows that match the sensitivity of each operation rather than treating login as a single gate.

Next up — Chapter 12: User Lifecycle Management. We cover provisioning (JIT, bulk), SCIM as the standard API for cross-system user sync, de-provisioning (and why it's always the part that's broken), role mapping, and the particularly thorny identity architecture problem of multi-tenant SaaS.