JWT Authorised Party (azp) Claim

What the JWT authorised party claim does

The azp claim is most useful when a token could be associated with more than one client path, because it identifies the client application that was actually authorised to receive it. In practice, it helps defenders distinguish the intended recipient from other parties that may also see the token in an OAuth or OpenID Connect flow.

That matters because token misuse often begins with ambiguity. If a receiver, broker, gateway or downstream service accepts a token without checking the authorised party where the protocol or application design requires it, a token intended for one client can be replayed or misapplied in another context.

Why it matters for token validation

The claim is part of the broader problem of token audience and recipient validation. It is not a substitute for checking the token's issuer, audience, signature, expiry and intended use, but it adds an extra control point when the same identity provider issues tokens to multiple clients or when a front-end and back-end both touch the same token.

Defenders should treat azp as a consistency check: does the token's authorised party match the application that is presenting it? When that answer is wrong, the token may still be structurally valid yet operationally unsafe for the current client.

Common failure modes and integration mistakes

The most common mistake is to assume any valid JWT is automatically valid for any relying party in the same ecosystem. That is risky in federation, SSO and multi-client integrations, where one client may obtain a token that another component later processes.

A second mistake is to parse the claim but never enforce it. If applications log the value, display it, or pass it through middleware without comparing it to an expected client identifier, the claim becomes documentation rather than a security control.

Another source of confusion is the surrounding protocol design. Some token types and flows rely on explicit client binding, while others do not require an azp check in every deployment. The rule is not "always validate it", but "validate it where the issuing protocol and your trust boundary require it".

How to use it in a secure architecture

Use azp as one layer in a broader token acceptance policy. The application should know which client identifiers are legitimate for a given flow, and the token processing path should reject values that do not match the expected client.

That expectation is easiest to maintain when client registration, redirect handling, token exchange and downstream API acceptance are designed together. The more clients, brokers and APIs share a token, the more important it becomes to keep the authorised party check explicit and testable.

For teams building OAuth and OIDC integrations, NHIMG's OAuth 2.0 and OpenID Connect Guide for Identity Teams is a useful companion for understanding where client roles and token handling intersect. Token handling guidance in Token and Session Security Guide is also relevant because azp only helps when the rest of the token validation chain is sound.

Where it fits with other identity and access checks

azp should be read alongside the rest of the token's trust signals, not instead of them. It complements audience validation, issuer validation and signature verification, and it supports the practical goal of making sure a token is used by the client that was actually authorised for that issuance context.

When the architecture includes multiple clients, delegated flows or intermediary components, the authorised party becomes a way to reduce confused-deputy behaviour and accidental token acceptance. In those cases, validating the claim can materially narrow the chances of one client presenting a token that was meant for another.

For a broader view of client and authorization relationships, Authorisation Models Guide helps place token checks inside the larger access-control picture. If your environment uses machine or workload identities, Guide to SPIFFE and SPIRE shows how service identity and token-based trust can be connected in practice.

Risk and Threat Considerations

When azp is ignored or inconsistently enforced, a valid token can be accepted by the wrong client context. That creates a misuse path where a token intended for one application is replayed, forwarded or accepted elsewhere, especially in multi-client and federated environments.

Failure mechanism: The accepting service fails to compare the authorised party in the token with the expected client identifier, so a token remains technically valid but is no longer bound to the correct recipient.

Impact: The result can be token confusion, inappropriate token acceptance, confused-deputy behaviour and, in some architectures, unauthorized access to downstream resources that trusted the token's original client context.

Practitioner Guidance

What to watch for: Enforce azp only where your token design and trust boundaries require a specific client binding. In practice, that means defining the expected client identity for each flow and testing that the receiving application rejects tokens whose authorised party does not match.

Practitioner takeaway: Treat the claim as a recipient-integrity check, not a standalone permission signal. It is most valuable when the rest of the validation path is already strict and the application knows exactly which client should be presenting the token.

Related resources from NHI Mgmt Group

• How should security teams use the JWT aud claim in production applications?
• What breaks when JWT claim semantics are not standardised?
• How should security teams design JWT claim based routing in API gateways without creating brittle access paths?
• What happens when JWT claim based routing is used without a separate authentication layer?