aud (Audience) Claim in a JWT

The audience is the set of recipients the token was minted for. RFC 7519 says a verifier that does not identify itself with a value in aud must reject the token. That single rule is what keeps a token issued for a low value internal service from being carried across and accepted by the billing API, so skipping the check quietly turns every service in the estate into the weakest one.

There are two encodings and both are legal. The general case is a JSON array of strings. As a shorthand, a single audience may be written as a bare string. Consumers have to handle both, which is exactly where hand rolled checks fail: comparing the claim to a string with a simple equality test works until the issuer starts emitting a one element array and every request begins failing at once.

What goes in the value is a naming decision, not a security one, but a bad choice makes the check useless. Identity providers usually want the resource URL of the API, such as https://api.example.com, because it is unique and already meaningful. A human label like Reports API is fine until a second environment uses the same label and a staging token starts passing production checks.

The decoder shows aud under Registered claims as Audience and renders an array as JSON rather than joining it into one string, so you can see whether the issuer sent one value or several. It does not know which service you are, so it cannot tell you whether the audience matches: that comparison belongs in the code that consumes the token.