JWT audience validation failures create replay risk across services

At a glance

What this is: This is an analysis of JWT aud claim validation and the key finding is that skipping audience checks allows token replay across services.

Why it matters: It matters because IAM teams, API owners, and identity architects need to treat audience validation as a core trust boundary, not a secondary JWT detail, across human, NHI, and service-to-service access flows.

👉 Read WorkOS's analysis of JWT audience validation and token replay risk

Context

JWT audience validation is the control that ensures a token is only accepted by the service it was actually minted for. In a multi-service environment, signature validation alone proves the token is authentic, but not that it belongs in the receiving context. That is why aud exists, and why teams that skip it create replay exposure across APIs and internal services.

For identity programmes, this is not just a developer hygiene issue. The same trust mistake shows up whenever one identity assertion is reused across multiple relying parties without a clear recipient check. In practical IAM terms, audience validation is part of scoping trust, limiting lateral use of valid credentials, and preserving the boundary between authentication and authorisation.

Key questions

Q: How should security teams validate JWT audience claims in multi-service environments?

A: Security teams should require every JWT verifier to check the aud claim against the receiving service identifier before any downstream authorisation logic runs. The best pattern is to use the library’s built-in audience validation, keep audiences unique per service, and reject tokens that were minted for another backend even when signature and issuer checks pass.

Q: Why do valid JWTs become dangerous when audience validation is skipped?

A: A JWT can be cryptographically valid and still be misused if the receiving service was not the intended audience. Without aud checking, a bearer token issued for one API can be replayed against another trusted API, turning normal federation into cross-service credential reuse. The risk grows when multiple services share the same issuer.

Q: What do security teams get wrong about the aud claim in JWTs?

A: The most common mistake is treating aud as optional, broadening it to cover many services, or reusing it for roles and permissions. That breaks the recipient check the claim was designed to provide. Audience should identify where the token is valid, while scopes and roles should describe what the token can do.

Q: Who is accountable when a JWT token replay attack succeeds across services?

A: Accountability usually sits with the service owner that accepted the token without validating audience, plus the platform team that allowed inconsistent JWT policies across APIs. In regulated environments, this also becomes a governance issue because a missing recipient check is a preventable trust-control failure, not an unavoidable user action.

Technical breakdown

Why audience validation is the real recipient check

The aud claim identifies the intended consumer of a JWT. A token can be signed correctly, issued by a trusted authority, and still be unsafe for a specific service if that service is not named in aud. That matters because token replay does not require token forgery. The attacker only needs a valid token that was issued for a different relying party. RFC 7519 allows aud to be a string or array, which means validators must handle both forms consistently. The security property is simple: the receiver must prove it is the intended audience before using any other claim.

Practical implication: make audience validation mandatory in every token verification path, including internal APIs and development environments.

How replay happens when audiences are too broad

A broad or shared audience value collapses service boundaries. If multiple APIs accept the same audience, then a token for one service can often be forwarded to another without failing validation. The problem becomes worse when teams confuse aud with roles or permissions, because the claim stops identifying a recipient and starts acting like a policy field. That misuse weakens both validation and debugging. Audience checks should be service-specific, not organisation-wide, and the check must be independent from scope or role enforcement. Those other claims answer what a token can do, not where it can be used.

Practical implication: assign unique audience identifiers per service and keep roles, scopes, and audience in separate claims.

Why issuer validation alone is not enough

iss tells you who created the token. aud tells you who should accept it. Those are different trust questions, and treating them as interchangeable creates subtle acceptance bugs. A token from a trusted issuer may still be inappropriate for a specific backend if it was minted for another consumer. In distributed systems, this mistake often survives testing because the token is still structurally valid. The failure appears only when a credential is replayed across services with different privilege boundaries. Correct validation must combine issuer, audience, expiry, and downstream authorisation checks.

Practical implication: verify issuer and audience together, then apply service-specific authorisation after the token is accepted.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Audience validation is a trust-boundary control, not a token-format detail. The article’s core lesson is that JWT validity is contextual, not universal. A correctly signed token is only safe when the receiving service is the intended audience, which makes aud part of the identity boundary itself. For IAM teams, the consequence is clear: token acceptance logic is a policy decision, not just a library call, and it must be treated that way.

Shared-token acceptance creates identity blast radius across services. When one issuer feeds multiple APIs, every omitted audience check expands the blast radius of a single credential. That is not a theoretical edge case. It is the operational condition that turns a routine access token into a replayable bearer credential across unrelated workloads. The practical conclusion is that trust scopes must be service-specific, because shared acceptance destroys separation of duties between APIs.

Audience overloading is a named failure mode that weakens JWT governance. Using aud for roles, wildcards, or organisation-level identifiers turns a recipient check into an ambiguous field and removes the safety property the claim was created to provide. This is a governance failure, not just a coding mistake, because it breaks the assumption that recipient identity is explicit and stable. Teams should treat audience overloading as a control defect in JWT design, not as a harmless shortcut.

JWT validation and NHI governance converge on the same principle: a valid credential is not automatically valid everywhere. Service accounts, workloads, and API tokens all need recipient scoping, because bearer-style trust is only safe when the intended use is tightly defined. That makes audience validation part of the broader NHI control stack, even when the immediate implementation lives in application code. Practitioners should treat token replay resistance as a core identity governance requirement, not a narrow API concern.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, showing that identity exposure is accelerating around AI infrastructure as well as code repositories.
• Credential governance now needs a separate control plane for recipient scoping and lifecycle handling, which is why the Top 10 NHI Issues remain relevant even in application-token scenarios.

What this signals

Recipient scoping is becoming a first-class identity control. As service meshes, APIs, and automation layers multiply, the practical question is no longer whether a token is valid, but whether it is valid here. Teams that already struggle with secret sprawl should assume similar drift in JWT policy consistency and align their verifier standards to the Guide to the Secret Sprawl Challenge.

Identity blast radius shrinks only when token acceptance is service-specific. The broader lesson is that bearer credentials need a use boundary, not just an issuance boundary. That aligns with zero trust logic and with the 52 NHI breaches Report, where valid credentials repeatedly became attack paths once trust was overextended.

JWT audience validation belongs in the same programme view as NHI governance. Even when the subject is an application token, the operational issue is still the same: prevent a credential from being accepted outside its intended context. That is why service-specific identity scoping should sit alongside token rotation, secret discovery, and access review in the identity roadmap.

For practitioners

• Require explicit audience checks in every verifier Configure JWT validation to reject any token whose aud does not match the receiving service identifier, including internal APIs and non-production environments. Do not rely on signature and issuer checks alone, and do not hand-roll comparison logic when the library supports audience enforcement.
• Give each service a unique audience value Replace organisation-wide or wildcard audiences with a service-specific URI or identifier so a token issued for one backend cannot be forwarded to another. Keep audience values stable, documented, and separate from scope or role claims.
• Separate recipient checks from authorisation data Store roles, permissions, and scopes in dedicated claims, and reserve aud for the intended recipient only. This avoids ambiguous parsing, preserves replay resistance, and makes validation failures easier to detect in logs and tests.
• Log audience mismatches as suspicious events Treat a valid token hitting the wrong audience as a replay signal and send it to monitoring, not just a generic authentication failure bucket. That gives defenders a traceable indicator of token forwarding attempts across services.

Key takeaways

• Skipping JWT audience validation turns a valid token into a replayable credential across services, even when signature and issuer checks succeed.
• The failure becomes worse when teams use broad audiences or overload aud with roles, because recipient scoping disappears and the trust boundary collapses.
• Practitioners should make aud checks mandatory, service-specific, and separate from authorisation logic so token acceptance stays bound to the intended backend.

Key terms

• Audience Claim: The audience claim, or aud, names the service or services a JWT is intended for. It is a recipient check, not an authorisation field. In practice, it limits where a valid token can be safely accepted and is one of the main defences against token replay across services.
• Token Replay: Token replay happens when a valid credential is reused in a different context than the one it was issued for. The token may be genuine, unexpired, and correctly signed, yet still unsafe because the receiving service never confirmed it was the intended audience.
• Audience Overloading: Audience overloading is the misuse of the aud claim for roles, permissions, wildcards, or organisation-wide identifiers. That practice destroys the claim’s meaning as a recipient check and creates ambiguity that can lead to token acceptance outside the intended service boundary.
• Bearer Token: A bearer token is a credential that grants access to whoever presents it, without additional proof of possession at use time. Because possession is enough, bearer tokens require strong scoping, strict validation, and careful audience checks to avoid accidental or malicious reuse.

Deepen your knowledge

JWT audience validation and service-specific token scoping are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are tightening API trust boundaries or modernising JWT controls, it is worth exploring.

This post draws on content published by WorkOS: How to validate the JWT aud claim and why it matters. Read the original.