The azp (Authorized Party) Claim

azp names the party an ID token was issued to. When present it holds that party's OAuth 2.0 client ID, and its value is a case-sensitive string.

That is the whole definition. Almost everything else written about azp describes a rule that OpenID Connect Core no longer states, which is why the claim causes more confusion than a single optional string should.

What the specification says now

OpenID Connect Core 1.0, incorporating errata set 2, makes three statements about azp in the ID token section:

• It is OPTIONAL.
• If present, it MUST contain the client ID of the authorized party.
• In practice it only occurs when extensions beyond the scope of the specification are in use, so implementations not using such extensions are encouraged not to use it, and to ignore it when it does occur.

The third point is the one that surprises people. azp is not a general-purpose field for recording who asked; it is a hook that specific extensions may define behaviour for, and a provider that implements no such extension has no reason to emit it at all.

Why most explanations disagree

Earlier revisions of the specification carried a concrete rule that is still quoted everywhere. The pre-errata text said the claim was only needed when the ID token had a single audience value and that audience was different than the authorized party, and that it may be included even when the authorized party was the sole audience. That is where the familiar summary comes from: "azp appears when aud is not the client".

Errata set 2 removed it. The current text does not tie azp to the shape of aud, does not require it in any situation, and pushes implementations away from emitting it. Anything you read that explains azp in terms of a single audience differing from the client is describing superseded text, and the difference is not cosmetic: it changes the claim from "usually present in this case" to "usually absent".

The practical consequence is that neither presence nor absence of azp tells you anything on its own. It is not a signal you can build a check on unless the provider documents an extension that defines it.

azp compared with aud

The two claims answer different questions, and only one of them is something a client validates unconditionally.

An ID token's audience is its client, so in the ordinary case aud already carries the client ID and azp would only repeat it. The claim earns its place only where an extension makes the requesting party distinguishable from the audience, and where that extension says what to do about it.

What a client should validate

Section 3.1.3.7 sets the validation rules for an ID token, and azp is a conditional entry in that list rather than a step of its own.

• Validate iss, aud, signature, exp and nonce as always. These are unconditional and are where the security of the token actually rests.
• If the implementation uses an extension that results in azp being present, validate the value as that extension specifies.
• That validation MAY include checking that the client's own client ID is the value.

Written as code, the rule is: do not require azp, do not reject a token for lacking it, and do not silently ignore it either when your provider documents a meaning for it. Rejecting tokens that carry no azp is the most common way to break interoperability with a conformant provider, because a conformant provider is encouraged not to send one.

There is one more azp rule that only appears during a refresh. Section 12.2 provides that where extensions put azp in the original ID token, they may require the refreshed token to carry the same value, and where the original had none, they may require that the new one has none either. Consistency across a session is therefore an extension's business, not something a client can assume by default.

azp and access tokens

azp is defined for ID tokens. The JWT profile for OAuth 2.0 access tokens, RFC 9068, does not use it: an access token identifies its client through the client_id claim. A JWT that carries azp but no client_id is therefore shaped like an ID token, and that distinction is useful when a token arrives without its context, such as at a token exchange endpoint.

azp in Abblix OIDC Server

Abblix OIDC Server reads azp and does not issue it, which follows the current specification directly: no shipped extension gives the claim a meaning here, and the specification asks implementations in that position not to emit it.

Reading it has one concrete use. JwtSubjectTokenResolver has to work out which client a subject_token was issued to, so that a pairwise sub can be opened against the right sector and the confused-deputy guard has an origin to compare against. Access and refresh tokens name their client in client_id; an ID token does not, and identifies its client through a sole audience or, where several audiences are present, through azp. The resolver therefore takes client_id, then azp, then a sole audience, in that order. A token with several audiences and neither claim leaves the origin genuinely undeterminable, and the resolver records it as unknown rather than guessing.

Common mistakes

• Requiring azp. A conformant provider is encouraged not to send it. A client that rejects tokens without it will fail against most providers.
• Deriving authorization from it. azp says who requested the token, not what that party may do. Scope and audience carry the authority.
• Assuming it appears whenever aud has several values. That was never quite the old rule, and it is not the current one.
• Trusting it without the signature. Like every claim in a JWT, azp means nothing until the token's signature is verified against the issuer's keys.