The JWT authorised party (azp) claim identifies the client application that was authorised to obtain the token. For example, when one client receives a token intended for multiple parties, the server can check which client actually requested it. Defenders use azp checks to reduce confusion between apps and to catch token misuse across clients.
What does azp mean in a real token exchange?
The azp claim matters when a token can be presented by more than one client or where multiple apps participate in the same flow. In practice, it gives the resource server a way to distinguish the client that was actually authorised to obtain the token from other parties that may also be able to see or relay it. That makes validation more precise than relying on audience alone.
A common example is a front-end application and a backend client both involved in a single sign-in or API call chain. If the token is shared across components, azp identifies which client was approved at issuance time, so the server can compare that value against the expected client for the request path. That is especially useful when tokens are forwarded through gateways, brokers, or intermediary services.
For an example payload, a JWT might include an azp value such as "azp": "client-frontend-123". In that case, the token was authorised for that client, even if the same user session or authentication event also touches other components. The practical check is simple: the receiver confirms that the token’s azp matches the client it expects to be using that token.
Where azp fits in OAuth and OpenID Connect validation
azp is not a replacement for issuer, audience, signature, or expiry checks. It adds a client-specific validation step when the token situation is ambiguous, such as when a token could be used across multiple consumers or when a platform issues tokens that traverse several application boundaries. The point is to bind the token more tightly to the authorised client relationship.
That is why azp is most useful in designs where client identity affects trust decisions. A resource server may accept the token only if the audience is correct and the authorised party matches the application that initiated the request. In operational terms, azp helps prevent one client from presenting a token that was actually minted for another client in the same ecosystem.
When you review an implementation, read azp alongside the rest of the token claims and the application’s client registration. The claim is only meaningful if the server has a clear expectation of which client should be associated with the request. If the environment does not distinguish clients in a material way, azp will add little beyond the standard JWT checks.
What azp protects against in practice
azp is most valuable where token confusion is the real risk, not just token theft. If a token can move through several apps, a server that does not verify the authorised party may accept a token in the wrong context and attribute the action to the wrong client. That can create authorization errors, audit confusion, or unexpected cross-client access paths.
It also helps when one client is more privileged than another. If the token was issued in a multi-client flow, checking azp can stop a lower-trust component from presenting a token that was meant for a different application boundary. The control is narrow, but it is useful in systems where multiple clients share sessions, brokers, or delegated access patterns.
At the design level, treat azp as a claim that supports client binding, not as a standalone security feature. It works best when combined with strict token validation, constrained audience values, and clear client registration rules. If those other controls are weak, azp alone will not make a token trustworthy.
Risk and Threat Considerations
azp becomes important when one token can be replayed or forwarded across more than one client context. The main risk is client confusion: a resource server may accept a token from an application that was not the intended authorised party, which can blur accountability and widen the usable blast radius of a token.
Failure mechanism: An application or gateway accepts a JWT without confirming that the authorised party matches the client expected for that request path, so a valid token is used in the wrong client context.
Impact: The result can be cross-client token misuse, misleading audit trails, and unintended access where the receiver trusts the token but not the actual client relationship behind it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-63, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | azp supports client binding in federated token processing and validation. |
| Recommendation — Validate the token's client relationship before accepting it in the relying party. | ||
| OWASP ASVS | V10 — OAuth and OIDC | azp is an OpenID Connect token claim used in client-bound validation flows. |
| Recommendation — Check client-bound claims during OAuth and OIDC token validation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | azp helps ensure tokens are used by the client that was authorised to obtain them. |
| Recommendation — Bind token use to the authorised client and reject mismatched presentations. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Skipping client binding can let a valid token be used by the wrong client. |
| Recommendation — Verify the token's authorised party before accepting API requests. | ||
Practitioner Guidance
What to verify: Check that the resource server enforces azp only where the architecture actually has multiple client parties or delegation paths. If every token always belongs to one client, azp should be consistent but is usually not the primary control that protects the system.
Decision rule: If a token can travel through brokers, front ends, or downstream service calls, validate azp against the expected client identifier before trusting the request. If the client relationship is not deterministic, treat the token as incomplete evidence of who initiated the action.
Common mistake: Teams often validate signature and audience but skip the client-binding logic, which leaves a gap when several applications can legitimately participate in the same authentication flow.
Practitioner takeaway: azp is most useful when you need to prove which client was authorised to receive the token, especially in shared or delegated flows, so its value depends on having a precise expectation for client identity at the point of use.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org