Validate JWT Issuer and Audience

A valid signature proves that some trusted key signed a token. It does not prove the token was issued for this API. A service that checks only the signature can accept a token intended for a different resource that shares the same issuer or key set. OWASP's JWT guidance calls for validation of expected claims.

Write the token contract for each protected API. Include issuer, audience, allowed signing algorithms, key source, lifetime rules, and required scopes. Keep this configuration on the server. Do not let a token header or model-supplied parameter choose a new trusted issuer.

Claim matrix

Check exact audience values using the provider's documented format. A token may have multiple audiences; define which combinations are acceptable instead of accepting any list that contains a familiar substring. Resolve signing keys only from the configured issuer's trusted metadata. Avoid algorithm confusion by fixing accepted algorithms in server configuration.

Synthetic token test

Use an owned test issuer to mint tokens for two resource identifiers. Call a harmless endpoint with the right token, then with a token for the other resource. The second must fail before the handler reaches data. Repeat with wrong issuer, wrong algorithm, expired token, and missing scope. Finally, use a correctly validated token against another tenant's synthetic record to prove object authorization is separate.

Record claim classes and decision codes, not bearer values. If the API sits behind a gateway, test both gateway and application behavior; one layer may validate signature while another assumes audience was checked. A successful library decode is not an authorization decision. Re-run the matrix when the issuer, resource identifier, or gateway configuration changes.