Acr Values

What acr_values does in OpenID Connect

The acr_values parameter is a request-time signal, not a command. It lets the client ask for a specific authentication context class, but the authorization server still decides whether to satisfy that request, substitute a different context, or issue a token that reflects the user’s current session.

This makes acr_values useful when an application needs to request stronger assurance for a sensitive action, but it also means the client must treat the result as policy-dependent rather than guaranteed. The value is part of the authentication conversation, not a proof that a particular level was actually delivered.

Why acr_values matters for assurance and step-up

In practice, acr_values is most relevant where an application distinguishes between ordinary sign-in and higher-assurance access. It can help express that a login should meet a particular authentication context, but the real decision remains with the identity provider and the surrounding policy.

That distinction is important because different providers interpret authentication context differently. Some support explicit assurance classes, some map them to local policy, and some return whatever the current session satisfies. The client should therefore design for negotiation, not entitlement.

When you need a fuller implementation view of step-up flows, the OAuth Step-Up Authentication Challenge Guide shows how acr_values, max_age, auth_time and challenge handling fit together.

How servers and clients should interpret the value

The authorization server may use acr_values to select a stronger method, but the client should inspect what was actually returned in the token or response. If the requested assurance level was not met, the application may need to deny the action, ask again, or route the user through an alternative control.

Good implementations also avoid assuming that one string means the same thing everywhere. The semantics depend on the provider, the configured authentication methods, and the relying party’s own policy model. That is why the parameter is best treated as a negotiation input, not a universal assurance guarantee.

If you want to compare how assurance levels and relying-party expectations vary across ecosystems, the National Digital ID Schemes Map provides useful context on how different identity systems express and enforce assurance.

Common failure modes and implementation nuances

The biggest implementation mistake is to trust the request parameter more than the issued result. Another is to assume that a requested context class will force reauthentication when the server can legally reuse an existing session or fall back to a lower context. Both errors can leave applications believing they have stronger assurance than they actually do.

It is also easy to confuse acr_values with a hard authorization decision. It is not one. It influences authentication context selection, while actual access control still belongs in the application’s authorization logic and post-authentication checks.

Where acr_values fits in access design

acr_values is best understood as part of a broader assurance design, alongside session freshness, authentication method choice and step-up policy. It becomes valuable when a system needs to request a higher context before high-risk operations, but it should be paired with validation of the returned claims and with business rules that respond if the requested level is unavailable.

Used well, it improves clarity between client intent and server policy. Used badly, it creates a false sense of security because the request looked stronger than the actual authentication outcome.

Related resources from NHI Mgmt Group

• Values
• What breaks when OAuth step-up relies on acr_values alone?
• What is the difference between sensitive environment variables and ordinary configuration values?
• How should organisations measure values-driven IT?