Cybersecurity glossary
What is the Audience Claim (aud)?
Learn what the JWT audience claim (aud) is, why APIs must validate it, how multi-audience tokens work, and which failures let tokens be accepted by the wrong resource server.
Definition
The audience claim (aud) is a registered JWT claim that identifies the recipients—usually resource servers or APIs—for which the token is intended; verifiers must reject tokens whose audience does not include their own identifier.
Why the audience claim matters
A valid signature proves who issued a token—not that your API was the intended recipient. The audience claim (aud) closes that gap by naming the authorized consumers of the token.
Without aud validation, any service that trusts the same issuer can become a confused deputy: tokens meant for a low-risk API work against a high-value one.
What aud protects
Recipient binding
Ensures tokens are accepted only by the APIs they were minted for.
Cross-app replay reduction
Stops reuse of a token across unrelated resource servers sharing an issuer.
Clear token purpose
Separates access-token audiences from OIDC client audiences on ID tokens.
Defense in depth
Complements scopes, issuer checks, and object-level authorization.
How audience validation works
Client requests a token for a resource
Authorization requests include resource/audience indicators where supported.
Issuer sets aud
The authorization server embeds the intended API audience(s).
Client calls that API
The access token is sent only to the matching resource server.
API verifies signature and issuer
Cryptographic and iss checks establish a trusted assertion.
API requires its audience value
Token is rejected unless aud contains the API’s configured identifier.
Authorization continues
Scopes and object-level checks run only after audience matches.
Common aud mistakes
| Mistake | Impact |
|---|---|
| Skip aud validation | Tokens for other apps are accepted |
| Use one global audience for all APIs | Any API token works everywhere in the estate |
| Validate ID-token aud rules on access tokens | Wrong acceptance/rejection behavior |
| Accept any aud string from a trusted issuer | Attacker-chosen audiences still pass if present |
Audience hardening checklist
- Configure each resource server with an exact expected audience value.
- Reject tokens missing aud or lacking your identifier in an aud array.
- Prefer per-API audiences over a single shared audience string.
- Align OAuth resource indicators with the aud values you enforce.
- Keep ID token and access token audience validation profiles separate.
- Include negative tests: valid signature, wrong aud, expect 401.
- Document audience identifiers in API onboarding checklists.
- Monitor repeated wrong-audience failures for misconfigured or probing clients.
The practical takeaway
The audience claim (aud) answers “who is this token for?” Signature checks alone are not enough.
Enforce an exact audience match on every resource server, avoid mega-audiences, and pair with issuer, expiry, and authorization controls so tokens cannot wander across your API estate.
Related security terms
Issuer Claim (iss)
Identifies who minted the token that carries the audience.
Access Token
Credential that should be audience-restricted to specific APIs.
JWT Claim
Broader overview of JWT payload assertions.
OAuth 2.0
Framework where resource indicators and audiences constrain tokens.
JSON Web Token (JWT) Attacks
Attacks that succeed when claim checks like aud are skipped.
Frequently asked questions
What is the aud claim in simple terms?
aud says which application or API the token is meant for. If your API is not listed, it should refuse the token even if the signature is valid.
Can aud be a list?
Yes. RFC 7519 allows a string or an array of strings. Verifiers accept the token only if their expected audience value appears.
What happens if APIs skip aud checks?
A token minted for App A may be replayed against App B that trusts the same issuer, enabling confused-deputy style access.
What should aud contain?
Stable identifiers for resource servers—often API URIs, client IDs, or logical audience names defined by the authorization server.
Is scope a substitute for audience?
No. Scopes limit permissions; audience limits which servers should accept the token at all. Use both.
Do ID tokens and access tokens use aud differently?
ID token aud is typically the OIDC client ID. Access token aud should identify the resource API. Do not mix those validation rules.
How do multi-API platforms handle audience?
Prefer distinct audiences per API or use resource indicators so tokens are not broadly valid everywhere.
References
Explore authoritative guidance and frameworks related to audience claim (aud).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.