2026-09-06 · 6 min read · Rahul Chitturi
- jwt
- oauth
- security
The JWT aud claim may be one string or an array of strings. A token can be correctly signed and unexpired yet fail because one verifier expects only the scalar form, compares the wrong service identifier, or treats an array as one serialized value.
Audience validation answers whether this token was intended for the current recipient. Skipping it to resolve a 401 can let a token issued for another API cross a trust boundary.
Compare typed claim values
Decode a synthetic or redacted token and inspect the JSON type before comparing values. Configure the accepted audience from the API's documented identifier, not from whichever hostname happens to receive the request.
- Accept scalar and array forms only as the selected profile permits
- Require at least one exact configured audience match
- Do not use substring, suffix, or case-insensitive matching
- Keep audience checks separate from scopes and roles
Map every validation boundary
A gateway and application may both validate tokens but use different identifiers or library defaults. Record issuer, accepted audiences, algorithms, key source, clock tolerance, and forwarding behavior at each layer.
Do not rewrite aud in transit or trust an unsigned header containing decoded claims. Each authorization component should validate the original token according to its own documented profile.
A Flashman workflow
Use the JWT tool to inspect safe claims, JSON formatter to expose scalar and array types, diff to compare environment settings, URL tool for identifier syntax, and timestamp converter for time claims.
Test one audience, several audiences, no match, similar prefixes, wrong case, missing aud, wrong issuer, expired tokens, gateway-to-service forwarding, and library upgrades.