Notifications
Clear all
Topic starter
06/06/2026 11:18 am
TL;DR: Skipping JWT audience validation lets a valid token issued for one service be replayed against another, even when signature, issuer, and expiry checks all pass, according to WorkOS. The control is simple, but the failure mode is structural: trust assumptions break when multi-service tokens are accepted without explicit audience checking.
NHIMG editorial — based on content published by WorkOS: How to validate the JWT aud claim and why it matters
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Separate recipient checks from authorisation data Store roles, permissions, and scopes in dedicated claims, and reserve aud for the intended recipient only.
What's in the full article
WorkOS's full article covers the implementation detail this post intentionally leaves for the source:
- Library-specific JWT verification examples for common backend stacks and how to wire aud enforcement correctly.
- Code patterns for handling string and array audience values without silently bypassing validation.
- Concrete debugging workflow using the WorkOS JWT Debugger to inspect aud, iss, and exp claims.
- Examples showing how to distinguish audience checks from scope and role authorisation in production systems.
👉 Read WorkOS's analysis of JWT audience validation and token replay risk →
JWT aud claim validation: are your service tokens really scoped?
Explore further
06/06/2026 12:01 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: JWT audience validation failures create replay risk across services
