Step-Up Authentication

Uniform authentication strength forces a bad choice: high friction on every login, which drives workarounds and abandonment, or low friction everywhere, which leaves high-value actions under-protected.

Step-up resolves it by varying the requirement with the value and reversibility of the action. Browsing needs a session; adding a payee, exporting customer data, changing bank details or altering production configuration needs fresh, strong proof.

Two properties make it work in practice. Users accept friction whose reason is visible — a prompt when transferring money reads as reassuring, while the same prompt on a dashboard reads as an obstacle. And most sessions never encounter it, so the conversion cost that security debates assume largely does not materialise.

Implementation notes. The token or session must record when and how the user authenticated, so a resource can require a recent strong authentication rather than merely a valid session — OIDC supports this directly through auth_time and acr. And the tiering must be written down as policy rather than living in scattered handler code, or it drifts and cannot be audited.

The internal case is the one most often neglected: administrative actions on production usually deserve step-up more than any customer action, and the friction costs almost nothing.