JWT Audience Mismatch: Verify the Signature, Then Check the Recipient

A token can have a correct signature and still be intended for another API. An audience mismatch means your configured recipient check did not accept the token’s aud value. Investigate that check separately from the signing key: changing keys will not repair a recipient mismatch.

This guide uses synthetic examples in the JWT diagnostics tool. It does not establish a bank-specific token profile, permission to access an API or conformance with an open banking standard.

Reproduce a real signature with a wrong audience

1. Paste a signed test JWT into the JWT tool; its header and payload appear automatically.
2. Expand Verify signature and claims (optional) and paste the corresponding public JWK or JWKS.
3. Select the issuer's documented signing algorithm and enter an expected audience different from the token's aud. Click Decode and Validate JWT.
4. Observe Signature — Passed and Audience — Failed. These outcomes are compatible.

For example, the expected recipient might be https://sandbox.example.com. while the token contains https://production.example.com. Those addresses are invented demonstration values, not provider endpoints. The token is signed correctly, but it does not target the configured recipient. For a comparison case, use a test token issued for the expected audience.

Compare the expected audience with the token contract

Under RFC 7519, the audience claim may be one string or an array of strings. A match against an expected recipient is case-sensitive. The issuer’s integration documentation determines what that recipient identifier should be; it is not necessarily the API’s visible URL. Source: RFC 7519, audience claim.

Do not automatically lowercase values, remove trailing slashes or replace the expectation with whatever the token says. That would change the check instead of diagnosing it. In this tool, leaving Expected audience empty produces Not checked, not a successful recipient check.

Fix the environment or token request, not the verification boundary

Use a small configuration worksheet with four entries: authorization environment, expected issuer, requested resource and expected audience. Compare each entry with the documented integration. A copied production client setting in a sandbox application is a useful hypothesis, but it is not the only cause: the application may have requested a different resource or received a different token type.

Trace where your application gets its expected audience. If a deployment variable is wrong, correct it through the normal configuration workflow. If the request targets the wrong resource, correct the request and obtain a new token. Editing the token’s payload changes the signed bytes and invalidates the signature. Disabling audience verification can hide a configuration problem while weakening recipient isolation. Source: JWT best current practices, audience validation.

After a correction, verify the signature, issuer and time checks again. A recipient match alone does not establish permission, scope, consent state or revocation status. The checklist is a snapshot of the selected checks, not an authorization decision.

Keep the failure reproducible

Include a valid signed token with the correct audience, a correctly signed token for a different audience, an audience array containing the expected recipient and a missing-audience case. A separate altered-payload fixture should fail signature verification. These cases help prevent future refactoring from conflating key problems with policy failures.

The nine-case Node.js verification lab provides a downloadable, repeatable starting point with disposable keys and a fixed clock. For browser debugging, use Copy safe diagnostic summary to copy check statuses without the token or claims. Record expected values separately only when appropriate for your team’s data-handling policy.

Sources and scope

Prepared 23 October 2026. The browser scenarios and exact-match tests are covered by the repository’s automated tests. This AI-assisted guide combines the linked IETF specifications with a proposed troubleshooting workflow; example identifiers are synthetic.