Token Audience Validation
The audience claim names who a token is for; accepting tokens minted for a different API — or skipping audience checks entirely — lets one service token work everywhere.
Definition
Audience (aud) validation checks that the token was issued for this API. A token minted for API A presented to API B must be rejected even when the signature and issuer are valid, because scopes and authorization decisions were made in another context. Missing audience validation turns any token theft into cross-API access.
Context and scope
Recurring JWT and OAuth bug in microservice fleets: gateways validate signature and issuer, services skip audience, and internal tokens roam freely.
Common misconceptions
- Signature validity implies the token is for you — signatures prove who issued it; aud proves who may consume it
- A shared issuer means shared tokens — one issuer serves many audiences precisely so that validation can differ per API
- Internal services can trust any internal token — blast radius of a leaked token multiplies with every service that skips aud checks
Anti-patterns
- Validating issuer and signature at the gateway while downstream services accept whatever the gateway forwards
- Configuring audience validation as optional per environment and forgetting it in production
- Reusing one audience value across many APIs to simplify configuration, collapsing isolation
Related concepts
Related examples
Authoritative source
What it is
A token is a letter, not a keyring: it is written to a recipient. The aud claim is the envelope address. A correctly signed letter for a different recipient, presented to you, is still not your mail.
How it works
Validation chains claims: iss says who minted it, aud says which API it is for, exp and nbf bound time, azp and scope bound what it may do. Each API checks its own audience value as a server constant. Gateways must pass the token but not launder it — forwarding is not validation.
When to enforce
Every API in the fleet, including internal ones. Central SDK defaults make audience mandatory; custom middleware is where the check goes missing. Integration tests should present cross-audience tokens and assert rejection.
Pitfalls
Multi-audience tokens and token exchange exist for delegation flows — handle them explicitly rather than accepting any list. Some services authenticate via introspection endpoints that return audience data; skipping that field reproduces the same hole server-side.