An audience restricted access token is issued for one named API, or a small set of them, and each API must refuse tokens meant for a different one. It limits what a leaked token can do. RFC 9700 says access tokens should be audience restricted and every resource server must verify that.
The problem
Imagine a partner receives a token to call your orders API. If that same token is also accepted by your billing API, a leak of the token exposes both. Worse, a malicious or compromised API that receives the token as a legitimate caller could replay it at another service.
Audience restriction closes that gap. The token says who it is for, and the receiving API checks.
What RFC 9700 says
The OAuth security guidance in RFC 9700 states that the privileges of an access token should be restricted to the minimum required. In particular, access tokens should be audience restricted to a specific resource server or, where that is not feasible, to a small set of resource servers. To put this into effect, the authorization server associates the token with certain resource servers, and every resource server is obliged to verify, for every request, whether the token was meant for that resource server. If not, it must refuse the request.
The document says the aud claim from the JWT access token profile may be used for this, and that clients and authorization servers may use the scope or resource parameters to say which resource server the client wants to reach.
It goes further: tokens should also be restricted to certain resources and actions on a resource server, and each server must check that the token was meant for that particular action.
Three layers of restriction
| Layer | Question | Mechanism |
|---|---|---|
| Audience | Is this token meant for me? | aud claim, resource parameter |
| Scope | Is this kind of action allowed? | scope claim |
| Resource and action | Is this operation on this object allowed? | Server side authorization checks |
Audience is the coarse outer wall. Scope and object level checks do the fine work inside it.
What each API must check
- Validate the signature and issuer of the token, or introspect it.
- Check that the aud claim names this API. If it does not, reject with 401 and invalid_token.
- Check expiry and any sender constraint, such as a DPoP or certificate binding.
- Check that the scope covers the operation.
- Check that the caller may act on the specific object.
Do not skip step 2 because the signature is valid. A valid signature only shows the token came from your issuer, not that it was meant for you.
Rolling it out
- Give each API a stable identifier to use as its audience, and document it for partners.
- Ask partners to request tokens for a specific resource, so the server can set aud correctly.
- Start by logging tokens whose audience does not match, then enforce.
- Keep a list of APIs that accept tokens for several audiences, and shrink it over time.
- For mobile apps, the same rule applies: a token for the app's backend should not be accepted by partner facing services.
Common mistakes
Accepting any token from your issuer, setting aud to a wildcard, forgetting to check it in internal services, and treating scopes as a replacement. Scopes describe actions. Audience describes the destination.
Safeguard's asset discovery helps you find API hosts and versions you may have lost track of, and its SBOM and dependency scanning shows which libraries ship in your builds. You can start with the free scan at gold.safeguard.sh/scan.
Quick check
Is a valid signature enough to accept a token?
No. The API must also confirm the token was meant for it, by checking the audience.
Does audience restriction replace scopes?
No. Audience limits where a token works. Scopes and object checks limit what it can do there.
Sources
- RFC 9700, OAuth 2.0 Security guidance (BCP 240)
- RFC 6750, The OAuth 2.0 Authorization Framework: Bearer Token Usage
Last reviewed: 19 October 2026.
