Skip to main content

Step-up authentication

Step-up authentication requires a user who is already signed in to complete additional verification before performing a sensitive action. Unlike MFA during initial login, step-up occurs mid-session – typically when a user attempts a high-value transaction, accesses protected data, or requests higher permissions.

How step-up works​

Step-up uses ACR (Authentication Context Class Reference) values and policies with recovery methods.

ACR values represent levels of authentication assurance. SecureAuth Connect supports configurable ACRs (default: aal1 and aal2) that map to specific authentication requirements via attached policies. A client application requests a specific ACR level by including acr_values in its authorization request.

When SecureAuth Connect evaluates the requested ACR:

  1. The policy attached to that ACR checks whether the current authentication session satisfies the requirement.
  2. If it does, the ACR is granted and included as a claim in the issued token.
  3. If it does not, the policy returns recovery methods specifying which additional factors the user must complete (for example, passkey, push, or OTP).
  4. The user completes the required factor.
  5. The token is issued with the requested ACR claim.
Step-up authentication flow

Scope-level step-up​

This same mechanism supports scope-level step-up: policies attached to specific scopes can require additional authentication before granting access to sensitive data. For example, a banking application might allow basic account viewing after password login but require passkey verification before initiating a transfer.

The amr (Authentication Methods Reference) claim in the token records which authentication methods were used, so the application knows how the user authenticated.

See also​