AZP Claim

Expanded Definition

The azp claim, short for authorized party, identifies the client or entity that a token was issued for and is allowed to present it. In practice, it helps a receiving service distinguish between the subject of a token and the application that is authorised to use it, which matters when JWTs move through gateways, brokers, or API layers.

In NHI and IAM workflows, azp is most useful when multiple software components can handle the same token family, but only one should be trusted as the intended caller. That makes it a control-relevant claim in token validation logic, especially where service-to-service access is mediated by automation. Definitions are largely consistent across identity implementations, although usage details vary across vendors and token profiles. For broader context on defensive outcomes, the NIST Cybersecurity Framework 2.0 frames authentication and access control as core protection functions.

The most common misapplication is treating azp as proof of identity, which occurs when teams use it to authorise the user or workload instead of validating the intended client application.

Examples and Use Cases

Implementing azp validation rigorously often introduces integration complexity, requiring organisations to balance stronger token integrity checks against additional gateway and claim-mapping logic.

• An API gateway checks azp before forwarding a JWT to downstream services, so only the expected client application can use that token.
• A service mesh validates azp to confirm that an automation client, rather than a different internal workload, is the authorised consumer of a delegated token.
• An identity platform uses azp alongside issuer and audience checks to prevent token confusion when multiple applications share the same authentication flow.
• A security team reviews azp handling after investigating a suspicious token replay path, using the claim to trace which client was intended to hold the token.
• Engineers compare azp to application registration data when designing machine-to-machine access for NHIs, ensuring the token matches the configured caller.

For related NHI risk context, NHIMG’s analysis of DeepSeek breach shows how exposed credentials and mismanaged access paths can widen the blast radius when token handling is weak.

Why It Matters in NHI Security

azp matters because token presentation alone does not prove the right application is using the token. In NHI environments, that distinction is critical: a secret, token, or certificate may be valid yet still be misused by the wrong client if validation is incomplete. Teams that skip azp checks often end up depending on brittle assumptions about where a token will travel, which is risky in distributed systems where gateways, orchestrators, and agents can all relay credentials.

NHIMG research on The State of Secrets in AppSec reports that the average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities. That gap shows how quickly token-related weaknesses can become operational failures when identities are not validated at the application boundary. Organisations typically encounter the consequences only after suspicious token use, at which point azp becomes operationally unavoidable to investigate and contain.

Related resources from NHI Mgmt Group

• What do security teams get wrong about the aud claim in JWTs?
• Who is accountable when privileged access failures affect a cyber insurance claim?
• Why do companion chatbots create compliance risk even when they do not claim to be human?
• Claim Minimisation