acr (Authentication Context Class Reference) Claim
acr names the authentication context class the login satisfied, as a single string agreed between the provider and the relying party. Its values are not standardized, so it means whatever the issuer documents it to mean.
At a glance
- Claim
- acr (Authentication Context Class Reference)
- Defined in
- OpenID Connect Core 1.0 section 2
- Value type
- String, often a URI, compared as an opaque value
- Required
- Optional. Returned when requested, or when the provider always emits it.
- Sample value
- urn:mace:incommon:iap:silver, or a provider specific value such as mfa
- In the decoder
- Shown under Custom claims with its raw value and no interpretation, which matches how opaque it really is.
In detail
acr is a single string identifying the level of assurance the authentication reached. OpenID Connect deliberately does not define a vocabulary beyond one special case: the value 0 means the authentication did not meet even ISO 29115 level 1, typically a long lived browser cookie, and the specification says such a session must not be accepted for a monetary transaction. Everything else is a name the parties agree on privately.
That is why the claim is easy to misread. Two providers can both emit acr and mean nothing alike; one uses URNs from an assurance framework, another uses short labels of its own invention. A relying party has to hold a list of the exact strings its provider issues and which of them it is willing to accept, and that list has to be revisited whenever the provider changes its authentication options.
A request can ask for a specific level using acr_values, or as an essential claim in the claims request parameter. The distinction matters: acr_values is a hint the provider may ignore, while an essential claim request is a stronger statement. Either way the outcome is only known by reading the acr in the returned token, so the comparison on the relying party side is what actually enforces the policy.
Where acr says how strong the authentication was, amr says which methods were used, and the two are often returned together. The decoder shows acr under Custom claims as a plain string. It cannot rank it, because there is no ranking to apply: interpreting the value requires the provider's documentation, not the token.
Examples
// Request, abbreviated
GET /authorize?...&acr_values=urn%3Amace%3Aincommon%3Aiap%3Asilver
// ID token payload
{
"acr": "urn:mace:incommon:iap:silver",
"amr": ["pwd", "otp"],
"auth_time": 1735686000
}Things that catch people out
- Treating acr values as ordered. There is no numeric ladder, so a string comparison against an allowed list is the only safe check.
- Accepting acr with the value 0 for anything sensitive. OpenID Connect explicitly says that level must not be used to authorize a monetary transaction.
- Sending acr_values and assuming it was honoured. It is a request, not a guarantee, and only the returned claim tells you what happened.
Try it: JWT Decoder
Paste a token to decode the header and payload, read the claims and expiry, and verify the signature in your browser. Nothing is uploaded.
JWT Decoder
LOCAL · Browser-OnlyDecode and inspect JSON Web Tokens without sending them to a server
Related JWT claims and algorithms
All jwt claims and algorithms →amr (Authentication Methods References) Claim
The amr claim lists how the user authenticated. The registered values from RFC 8176, why the list is not proof of strength, and what the decoder shows.
auth_time Claim in an OpenID Connect ID Token
The auth_time claim records when the end user actually authenticated, not when the token was issued. How max_age uses it and how the decoder shows it.
nonce Claim in an OpenID Connect ID Token
The nonce claim binds an ID token to one authentication request. How the value round trips, why it must be compared, and how the decoder shows it.
at_hash (Access Token Hash) Claim in an ID Token
The at_hash claim ties an ID token to the access token issued with it. How the left half hash is computed, when it must be checked, and decoder limits.
c_hash (Code Hash) Claim in an ID Token
The c_hash claim binds an ID token to the authorization code returned with it. Where hybrid flows need it, how it is computed, and what the decoder shows.
sid (Session ID) Claim in a JWT
The sid claim identifies the authentication session at the provider. How single logout uses it, why it is not the user identifier, and decoder behaviour.
Tools for this
- JWT Decoder Free online JWT decoder - decode and inspect JSON Web Tokens without sending them to a server