The azp (Authorized Party) Claim

azp names the party that requested an ID token - the authorized party, in the specification's words - as distinct from aud, which names who the token is for. 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 a 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, and declares itself an access token through the at+jwt value of the typ header, which a resource server MUST check.

That difference in claims describes the two formats; it is not a way to tell them apart. Where a token's kind matters, the kind is carried explicitly. Token exchange makes subject_token_type a required parameter for exactly that reason, so a token never arrives there without its type declared, and inferring the type from which claims happen to be present would replace a stated fact with a guess.

azp in Abblix OIDC Server

Abblix OIDC Server is certified by the OpenID Foundation across all login and logout profiles, and its handling of azp follows the current specification directly: it reads the claim and does not issue it, because 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, and it starts after the token's signature has been verified: an unvalidated JWT has no claims worth reading.

On a token that passed, the server works out which client it was issued to, so that a pairwise sub can be opened against the right sector and the cross-client guard has an origin to compare against. Access and refresh tokens name their client in client_id. An ID token has no such claim, so the server falls back to azp where the issuing provider emits one, and then to a sole audience. The order is a preference between three sources, not a rule about when azp appears.

When none of the three yields an answer the origin is genuinely undeterminable, and the exchange is refused rather than allowed to proceed on a guess. That is the only reading that keeps the check meaningful: a token shaped to hide which client it belongs to would otherwise clear a guard that a token naming another client fails. A client that legitimately brokers tokens it was not issued opts out of both refusals with one setting.

Common mistakes

• Requiring azp. A conformant provider is encouraged not to send it, so a client that rejects tokens without it will fail against any provider that follows the current text.
• 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.