azp (Authorized Party) Claim in a JWT
azp holds the client identifier of the party the ID token was issued to. It matters when the audience contains more than one value, because aud alone then no longer tells a relying party whether the token was minted for it.
At a glance
- Claim
- azp (Authorized Party)
- Defined in
- OpenID Connect Core 1.0 section 2
- Value type
- String, a case sensitive client identifier
- Required
- Required when aud has more than one value or when the party the token is for differs from the sole audience. Optional otherwise.
- Sample value
- web-dashboard
- In the decoder
- Shown under Custom claims with its raw value. Only the seven RFC 7519 claims are explained by name.
In detail
An ID token can legitimately list several audiences, for instance when one client asks for a token that a downstream service will also inspect. Once aud is an array, the question every relying party asks, was this token minted for me specifically, no longer has an answer in aud. azp answers it by naming the single client the authorization server issued the token to.
The rule in OpenID Connect Core is narrow. azp is required when the audience has multiple values, and required when the party the token was issued to is not the same as the only audience value. In the common single client case it is simply absent, so a missing azp is normal and not evidence of anything wrong.
For a relying party the check is short: if azp is present it must equal your own client identifier. That is in addition to the audience check, not instead of it. Skipping it in a deployment that does emit multiple audiences means accepting a token that another client was supposed to receive, with your identifier merely along for the ride in the aud array.
The decoder prints azp under Custom claims with the value exactly as it was encoded, and does not attempt to explain it or compare it with anything, because it has no idea which client you are. It is still the quickest way to see whether an authorization server is emitting the claim at all, which is usually the actual question when a library rejects a token for an authorized party mismatch.
Examples
{
"iss": "https://auth.example.com",
"aud": ["web-dashboard", "https://api.example.com"],
"azp": "web-dashboard",
"sub": "8f14e45fceea167a5a36dedd4bea2543"
}The relying party checks that azp equals its own client identifier, and that its identifier appears in aud.
Things that catch people out
- Treating a missing azp as a failure. It is only required when the audience has several values or differs from the party the token was issued to.
- Checking azp instead of aud. They answer different questions and a correct verifier checks both.
- Expecting azp in an access token. It is an ID token claim; access tokens issued under RFC 9068 identify the caller with client_id instead.
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 →aud (Audience) Claim in a JWT
The aud claim names who a token is for. Why every API must check it, how the string and array forms differ, and what the decoder shows.
client_id Claim in a JWT Access Token
The client_id claim names the OAuth client an access token was issued to. How it differs from sub and azp, where it is required, and decoder behaviour.
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.
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.
acr (Authentication Context Class Reference) Claim
The acr claim states how strongly the user was authenticated. Why its values are provider specific, what the value 0 means, and how the decoder shows it.
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.
Tools for this
- JWT Decoder Free online JWT decoder - decode and inspect JSON Web Tokens without sending them to a server