JWT audience validation failures create replay risk across services

At a glance

What this is: This article explains how ignoring the JWT aud claim allows tokens to be accepted by services they were never meant to reach.

Why it matters: IAM and API security teams need audience checks because signature validation alone does not stop token replay across shared identity providers.

Context

JWT audience validation is the control that ensures a token is accepted only by the service it was issued for. In multi-service environments, signature and issuer checks can still pass while the token is replayed against the wrong API, which turns a valid token into a cross-service access path.

The governance gap is not cryptographic verification itself but recipient scoping. When developers treat aud as optional, generic, or interchangeable with iss, the token no longer carries a reliable boundary between services, roles, and privilege levels.

Key questions

Q: What breaks when JWTs are signed without strict issuer and audience validation?

A: Without issuer and audience validation, a token may be accepted in the wrong application boundary or from the wrong trust context. That creates authorization confusion, weakens token replay defenses, and increases the chance that a valid token is treated as trustworthy where it should not be. Validation is part of proving token provenance and intended use.

Q: Why do JWTs become risky when service boundaries are inconsistent?

A: JWTs become risky when one service validates them properly and another does not. Attackers look for the weakest enforcement point, then reuse a valid token where checks are skipped or incomplete. Reused signing secrets, missing claim validation, and weak propagation controls can let a token issued for one context operate in another, which defeats the trust boundary the token was meant to preserve.

Q: How can security teams tell whether audience checks are working?

A: Audience checks are working when a token accepted by one service is consistently rejected by another unless that second service is explicitly listed in aud. Mismatches should generate logs or alerts rather than silent failures. If the same token works everywhere, the audience boundary is not being enforced.

Q: What is the difference between the iss and aud claims in a JWT?

A: The iss claim identifies who issued the token, while the aud claim identifies who the token is meant for. In practice, both checks matter because one confirms the source of trust and the other confirms the intended recipient. A valid issuer does not make a token usable everywhere, and audience validation prevents a legitimate token from being accepted in the wrong place.

Technical breakdown

How JWT audience claims scope token acceptance

The aud claim identifies the intended recipient or recipients of a JWT. A backend should compare its own service identifier against that claim before trusting the token, and it should do so whether aud appears as a single string or an array. This matters because a valid signature only proves the token was minted by a trusted issuer, not that it was meant for the service now receiving it. In distributed systems, multiple APIs can share the same issuer, so audience validation becomes the deciding control for token acceptance.

Practical implication: configure every service to enforce explicit audience matching rather than relying on issuer and expiry alone.

Why replay happens when audience checks are skipped

A token replay attack succeeds when a token issued for Service A is forwarded to Service B and B accepts it. The article’s core point is that this failure is structural, not exotic: once two services trust the same issuer, every valid token is technically portable unless aud is enforced. Overly broad audience values create the same problem by making multiple services look equivalent, which removes the recipient distinction that JWTs are supposed to preserve.

Practical implication: assign unique audience values per service and reject any token whose audience is generic or shared across APIs.

How aud interacts with iss, sub, scope, and azp

JWT claims have distinct jobs. iss identifies who created the token, aud identifies who should consume it, sub identifies the subject, and scope or roles define what that subject may do. Confusing these claims collapses authentication and authorization into one ambiguous check. The article also notes that azp can help identify the requesting client in multi-audience scenarios, but it does not replace aud. That separation matters because a token can be authentic, user-specific, and still be misdirected to the wrong service.

Practical implication: validate audience alongside issuer, then enforce authorization separately through scopes, roles, or dedicated permissions.

Threat narrative

Attacker objective: Use a valid token in a service it was never intended for, thereby extending access across application boundaries without forging credentials.

1. Entry occurs when an attacker or intermediary obtains a legitimate JWT issued for one service and forwards it to another service that trusts the same issuer. Because the token is valid and unexpired, it can pass initial verification if audience checking is missing.
2. Credential abuse happens when the receiving service treats the token as proof that it was meant for that endpoint, even though aud does not match the service identifier. The attacker does not need to forge the token, only replay it in a different context.
3. Impact follows when the wrong service accepts the token and authorizes actions based on claims that were intended for a different application. That can expand user privilege, expose internal APIs, or let a public-service token reach an admin surface.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Audience validation is a recipient-boundary control, not a JWT nicety: The aud claim is what stops a valid token from becoming portable across services. Signature checks only confirm origin, while audience checks confirm destination, and those are different security questions. In modern API estates, that distinction is the difference between contained access and cross-service replay.

The trust assumption that fails here is service equivalence: Many implementations assume that if two APIs trust the same issuer, the same token can safely move between them. That assumption fails because privilege is not identical across services, even when the token format is identical. The implication is that service identity must be explicit in token acceptance logic, not inferred from issuer trust.

Generic audience values create identity blast radius: When teams use organization-wide or wildcard audiences, they erase the very boundary aud was meant to enforce. A shared audience turns scoped tokens into reusable artefacts, which makes replay risk a property of architecture rather than attacker sophistication. Practitioners should treat audience design as part of access segmentation, not token cosmetics.

Token validation and authorization are separate governance layers: aud tells a service whether it is the intended recipient, while scopes and roles tell it what the subject may do. Conflating those layers creates subtle overreach, especially where a user has different privilege levels across services. The correct model is that aud gates acceptance, and authorization rules gate action.

Replay risk is a design symptom of multi-service trust without recipient specificity: The article shows that JWTs do not fail because they are weak tokens, but because systems accept them too broadly. That makes explicit audience validation part of access scoping, service isolation, and zero-trust style request evaluation. Practitioners should read aud failures as a boundary-design problem, not a parsing bug.

What this signals

Recipient scoping has become a core API security control: JWT validation is not complete until the service checks whether it is named in aud. That moves the control from token integrity to token destination, which is where replay resistance actually lives.

The practical risk is broadest where multiple APIs share one issuer but have different privilege levels. In that setup, audience design becomes part of segmentation, and a sloppy audience convention can silently widen access across services.

For practitioners

• Enforce explicit audience matching Require every API and backend service to validate aud against its own unique identifier before trusting any other claim. Do not accept tokens solely because iss and exp are valid.
• Assign service-specific audience values Use audience strings that identify one service or one clearly bounded API surface, not an organisation name or wildcard domain. Separate public API audiences from internal admin audiences.
• Handle string and array audiences Treat aud as either a single value or an array and reject tokens if your service identifier is absent in either form. Use library support where possible instead of custom comparisons.
• Log audience mismatches as replay signals Alert when a token with a valid signature and trusted issuer fails audience validation, because that pattern can indicate forwarding or replay attempts across services.

Key takeaways

• Skipping aud validation allows a valid JWT to be replayed across services even when issuer and expiry checks succeed.
• The control failure is architectural, because services that share an issuer but not an audience boundary can accept tokens meant for other APIs.
• Practitioners should enforce unique audience values, validate string and array forms, and treat mismatches as replay indicators.

Key terms

• Audience Claim: The audience claim is the value inside a token that identifies who or what should accept it. For non-human identity governance, it is the enforcement point that prevents a token issued for one resource from being accepted by another resource with a different trust boundary.
• Token Replay: Token replay is the reuse of a valid access or refresh token by someone other than the intended client. The token may still be unexpired and cryptographically correct, so the compromise often shows up only through context anomalies such as location, device, or session overlap.
• Recipient Binding: Recipient binding is the requirement that a token be accepted only by the specific service or services named for it. This is essential in multi-service architectures, where shared issuers can otherwise make tokens portable across boundaries.
• Audience Mismatch: An audience mismatch occurs when a service receives a token whose aud value does not include that service's identifier. It is a useful security signal because it often indicates forwarding, replay, or a configuration error in token validation.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.