How should platform teams decide between one shared audience and separate audiences?

What shared audiences and separate audiences are really deciding

A shared audience decision is an access-boundary decision, not just a token-format preference. If one token can move safely across environments, you are optimising for simplicity and operational reuse; if production needs a harder boundary, separate audiences prevent non-production tokens from being accepted before authorization logic even runs. That boundary is stronger when it is paired with a separate issuer for the highest-isolation cases.

In practice, the question is whether environment separation is meant to be informational or enforcement-grade. Shared audiences keep configuration and client behaviour simpler, but they also make token reuse across environments more plausible. Separate audiences reduce accidental cross-environment acceptance and make the intended trust boundary visible to both the platform and the application.

The useful test is whether accepting a token in production would be a harmless convenience or a real exposure. If a token from dev or staging could reach production endpoints, even briefly, the audience claim should be doing meaningful work. If all environments are intentionally interchangeable for the same workload or service, a shared audience can be acceptable because it avoids needless fragmentation.

When one shared audience is the better fit

Shared audiences work best when the same client or workload is supposed to behave the same way in every environment, and the token is only proving that the caller is allowed to use that family of APIs. In that model, the audience identifies the service, not the environment, so the token remains portable across dev, staging and production while RBAC still handles environment-specific permissions.

This is usually the right trade-off when platform teams are trying to avoid duplicated client registrations, duplicated token exchange paths, or brittle environment-specific configuration. It can also reduce operational drift, because developers and automation do not need to manage separate token audiences for each deployment stage.

The constraint is discipline: if you choose a shared audience, you must be confident that environment separation is enforced elsewhere, such as by RBAC, resource scoping, or deployment isolation. Without that, a shared audience becomes an easy way for a token minted in a lower environment to be accepted where it should not be.

When separate audiences, or a separate issuer, are the safer choice

Separate audiences are the right answer when production must reject non-production tokens before authorization is even considered. That is the cleaner design when development and staging are allowed to be loose, test-heavy, or lower-trust, but production needs a stricter gate that fails closed as early as possible.

A separate issuer goes one step further. It is the strongest option when the environments are not just different, but deliberately isolated in trust, administration, or blast radius. In those cases, the issuer boundary makes token provenance distinct, so a token from one environment is not merely under-privileged, it is structurally out of scope for the other.

This approach is especially valuable when teams have high assurance requirements, external integrations, or a history of environment bleed-through. It reduces ambiguity during incident response as well, because a token’s issuer and audience together tell you which environment minted it and where it was supposed to work. For audience design in OAuth-based systems, the resource indicator model in RFC 8707: Resource Indicators for OAuth 2.0 is the clearest reference point.

How to make the call without overengineering the token model

Use the narrowest boundary that still enforces the actual trust model. If production and non-production are operationally equivalent for the token’s purpose, shared audience is usually enough. If the environments have different trust levels, different permissions, or different consequences when a token is accepted, split the audience. If you need the strongest separation, split the issuer as well.

What to verify: confirm whether the audience is meant to identify a service, an environment, or both. Then check whether production can independently reject tokens from lower environments before any role or permission lookup occurs. The deciding factor is not whether separate audiences are possible, but whether they materially reduce the chance of an unintended token being accepted.

Common mistake: teams sometimes assume RBAC alone is enough to protect production. RBAC controls what an authenticated token may do, but it does not by itself stop a lower-environment token from being treated as valid. When the boundary matters, the audience claim should carry part of that load, and the issuer should be separated when trust domains truly differ.

Practitioner takeaway: Choose shared audiences for controlled reuse, choose separate audiences for enforcement-grade environment separation, and add a separate issuer when you need the trust boundary itself to be unmistakable.

Related resources from NHI Mgmt Group

• How should security teams decide between native ERP controls and a separate governance platform?
• Why do platform teams need separate services for billing, identity, search, and observability instead of bundling them into one shared layer?
• How should regulated teams decide between shared SaaS and tenant-owned identity platforms?
• How can teams decide between OPA, Cedar, Casbin, and an authorization platform?