Fix JWT Invalid Audience Errors
A JWT audience error means the token is not addressed to the verifier's protected resource. Request the correct token and validate its intended recipient without weakening checks.
Inspect claims without trusting them
Decode the header and payload locally to inspect iss, aud, exp, token type, scopes, and permissions. Decoding does not verify authenticity. Do not paste production tokens into third-party services or logs. Perform signature and claim validation with the issuer's documented keys and algorithms before authorizing any request.
Read the audience representation correctly
The aud claim can be one case-sensitive string or an array of strings. The protected API should require its configured audience to be present according to the authorization server contract. Avoid substring, prefix, or case-insensitive matching unless the provider explicitly defines such semantics. A similar-looking URL with another slash, scheme, tenant, or environment is a different value.
Request a token for the intended resource
Authorization servers use provider-specific audience, resource, scope, or API identifier parameters to choose the target service. Confirm which parameter belongs in the authorization or token request. A token issued for a user-profile API will not automatically be valid for a billing API. Start a new authorization flow after correcting the resource request.
Distinguish ID and access tokens
An OpenID Connect ID token describes authentication to a client and commonly names that client in its audience. It is not generally an access token for a custom API. Send the access token returned for the API's resource. At the server, validate the token type and required authorization claims in addition to issuer, signature, time, and audience.
Align issuer and environment
Use the discovery document and keys for the same issuer that minted the token. Development, staging, production, regional, and tenant-specific issuers can use different audience identifiers. Avoid a configuration that accepts several unrelated audiences merely to make tests pass. Keep each API's expected issuer and audience explicit and reviewable.
Handle multiple legitimate audiences narrowly
If one API intentionally supports multiple registered audience values, configure an explicit allowlist and test each value. Do not disable audience verification or accept the client ID as a universal fallback. In a multi-service architecture, prefer tokens minted for the called service or an authorization design that explicitly documents downstream delegation.
Retest full validation
Obtain a fresh token for the intended API and verify signature, issuer, audience, time claims, token type, and permissions. Test rejection of a valid token minted for a different API. Inspect non-secret examples with the JWT Decoder.
Frequently Asked Questions
Can aud be an array?
Yes. The required API audience must be present.
Is a trusted issuer enough?
No. Validate audience and every required authorization claim.
Can an ID token call an API?
Usually no. Use the access token intended for that resource.