Which OpenID Connect request parameters ask a provider for a stronger or a fresher sign-in, and how do they differ?

## Two different questions one request can ask A relying party that wants a stronger sign-in before a sensitive operation is really asking one of two questions, and OpenID Connect gives each its own parameter on the authentication request: - **"Authenticate them *this way*"** — `acr_values`. - **"Authenticate them *recently*"** — `max_age`. A dental laboratory's case-tracking site can let a practice browse its case queue on an ordinary sign-in, and demand one of these before it releases a patient's case record. They compose: a request may carry both. ## `acr_values`: which context, in order of preference `acr_values` is a **space-separated string** of authentication context class references, listed **in order of preference**. Each value is an opaque string whose meaning comes from a profile the relying party and the provider have agreed on; OpenID Connect itself defines no values, and an IANA registry exists for level-of-assurance profiles (`RFC 6711`). Grading what a level *means* — what an identity, authenticator or federation assurance grade demands — is a separate subject from the parameter that names one. The critical property is **how binding it is**. This parameter requests the `acr` claim as a **voluntary** claim: it expresses a preference, and a provider may authenticate the user some other way and return a context you never asked for. Three consequences follow: - The relying party **must read the returned `acr`** and decide for itself whether the request was satisfied. - A request that succeeds is not evidence that the requested context was used. - Making the context a hard requirement is a different mechanism — asking for `acr` as an *essential* claim through the `claims` request parameter — and even then the relying party still checks. A provider advertises the values it will accept in the `acr_values_supported` field of its configuration document, which is how an integration discovers the strings to send instead of guessing them. ## `max_age`: how recently, and with a MUST behind it `max_age` is an integer number of **seconds**: the allowable elapsed time since the end user was last actively authenticated by the provider. If the elapsed time is greater than that value, the provider **MUST attempt to actively re-authenticate** the user. That is a materially stronger obligation than `acr_values` carries. It also changes what comes back. When `max_age` is used, the ID token returned **MUST include** the `auth_time` claim — the time of that last active authentication — so the relying party can check the bound for itself rather than trusting that the provider applied it. Validating claims in the returned ID token is its own subject; what belongs here is knowing that sending `max_age` is what compels the provider to report the number you need. ## Side by side | | `acr_values` | `max_age` | |---|---|---| | What it asks for | the kind or strength of authentication | the recency of the authentication | | Value shape | space-separated context class references, in order of preference | an integer count of seconds | | Force | a request; `acr` is asked for as a voluntary claim | if elapsed time is greater, the provider MUST attempt re-authentication | | What the provider reports back | the `acr` claim, possibly not a value you sent | the `auth_time` claim, which MUST be present when `max_age` is used | | Advertised in provider metadata | `acr_values_supported` | not advertised as a capability | ## The failure this material actually produces The production failure is not a rejected request; it is a **successful** one. A site sends `acr_values`, receives a normal response, elevates the user, and releases the record — while the provider authenticated the user from an existing session with a weaker method entirely. Nothing errored. The habit that prevents it is stated once and applies to both parameters: **the request is an ask; the response is the evidence.** A second failure is subtler and comes from confusing the two axes. A user who authenticated with a strong method eight hours ago satisfies a strength request and fails a freshness one; a user who authenticated thirty seconds ago with a weak one is the reverse. Deciding which of those a given operation needs is a policy question about your own product, and where it is recorded and how long it stays true is your application's own business, not the protocol's. The protocol's contribution stops at giving you two precise ways to ask and two precise things to check in the answer. ## Practical sequence 1. Read the provider's `acr_values_supported` to learn the strings it accepts. 2. Send `acr_values`, `max_age`, or both on the authentication request for the operation that needs it. 3. When the response arrives, check the reported context and authentication time against what you asked for. 4. Treat a shortfall as a decision your service makes — not as something the successful response already settled.