The aud claim in multi-tenant JWTs: when to use it, what to put in it

aud (audience) is the JWT's defense against a token issued for one consumer being replayed against another. In multi-tenant apps, that defense matters.

Last updated: May 2026

shield

Private: Decoding, analysis, signature verification, and token generation all run in your browser. Nothing is sent to any server, except a JWKS URL you explicitly enter and click Verify on.

Paste your JWT

At a glance

Spec reference: RFC 7519 §4.1.3
Type: String or array of strings
Validation rule: Verifier must match its identifier
Common values: API URL, app id, tenant id

The `aud` claim says "this token is intended for these consumers". A consumer must verify it's in the audience before trusting the token. Without `aud`, a token your auth server issued for service A can be replayed against service B with no friction. In multi-tenant apps where services span tenants, this is exactly the cross-boundary leak you don't want.

How aud blocks cross-service replay

Imagine your auth server issues JWTs that the billing API and the analytics API both consume. Without `aud`, a token issued for billing is also valid against analytics — a frontend bug that leaks the billing token (e.g., embeds it in a third-party analytics request) effectively leaks analytics access too.

With `aud: "billing.example.com"`, the analytics API rejects the token because its expected aud (`analytics.example.com`) isn't present. The leak is contained to one service.

Frequently asked questions

What should I put in aud?expand_more

The intended consumer's identifier. For an API, use the API's URL or a stable app id (`https://api.example.com` or `app_acme_billing`). Each service that consumes JWTs validates that its identifier appears in `aud`.

Can aud include the tenant id?expand_more

Yes — combining the consumer + tenant in `aud` (e.g., `aud: ["api.example.com:tenant_acme"]`) gives you tenant-scoped audience validation. It's belt-and-braces with the regular tenant claim. Useful when you have shared services that handle multiple tenants and want defense in depth.

Can aud be an array?expand_more

Yes. Use an array when a token is intended for multiple services (e.g., a frontend that calls several APIs with one token). The verifier checks that its own identifier is *in* the array. Don't use array form for a single intended consumer — it's a weaker constraint.

Different SaaS auth providers use different claim names for the same concept. Here's when to use each, and how to migrate between them.

JWT permissions: scopes, roles, and how to encode them

Resource:action strings, OAuth scopes, bitmasks — which permission encoding to use in a multi-tenant JWT, and the trade-offs of each.