Scopes describe the permissions granted to a token, while audience identifies the resource or service that should accept it. A token can have the right scope but still be invalid for a specific API if the audience is wrong. Both checks are needed to keep reusable tokens constrained to the correct service context.
Why This Matters for Security Teams
OAuth2 scopes and token audience solve different authorization problems, and mixing them up creates a common control gap. Scopes answer what a token may do, while audience answers who should accept the token. That distinction matters because tokens are often reused across APIs, gateways, and automation paths. If audience validation is weak, a valid token can be presented to the wrong service even when its scopes look correct.
This is not a theoretical edge case. Token misuse is a recurring pattern in modern breaches, including the Salesloft OAuth token breach and the Vercel Context.ai OAuth Supply Chain Breach, where trust in token form was not enough. OWASP also treats token handling as a core NHI risk in the OWASP Non-Human Identity Top 10. In practice, many security teams discover the gap only after a reusable token has already crossed service boundaries and been accepted where it should never have worked.
How It Works in Practice
In a correctly designed OAuth2 flow, the authorization server issues a token with claims that describe both permission and intended recipient. Scopes are usually coarse-grained permission labels such as read:invoices or write:orders. Audience, often expressed as aud or a resource indicator, identifies the API or resource server that should validate and accept the token. A secure resource server checks both: does this token have the scope required for the action, and was it minted for this service?
That second check is what prevents token replay across services. A token with broad scope but the wrong audience should be rejected, because scopes do not prove the token belongs to this API. This is especially important in microservices, API gateways, and partner integrations where the same identity provider serves multiple backends. NIST guidance on access control, including NIST SP 800-53 Rev 5 Security and Privacy Controls, reinforces the need to validate authorization context at the point of access rather than assuming a token is universally valid.
- Use scopes to constrain action, not service selection.
- Use audience to bind the token to one resource server or API group.
- Reject tokens that are validly signed but issued for a different audience.
- Keep token lifetimes short when the token can reach multiple systems.
This matters even more when OAuth tokens protect non-human identities. The State of Non-Human Identity Security shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes tight audience enforcement and token scoping essential. These controls tend to break down when gateway, API, and identity teams each validate only part of the token and no single service enforces the audience claim end to end.
Common Variations and Edge Cases
Tighter token validation often increases integration overhead, requiring organisations to balance service isolation against developer friction. The right tradeoff depends on how reusable the token must be and how sensitive the API is. Current guidance suggests treating audience as mandatory for any token that can cross trust boundaries, while scopes remain the finer-grained permission layer inside that boundary.
There is no universal standard for audience handling across every OAuth profile. Some platforms use a single aud claim, others use resource indicators, and some API gateways enforce both at different layers. That variation is why implementation details matter more than the label on the token. For example, a token may carry broad platform scopes but still be safely limited if the resource server validates a narrow audience and the gateway blocks token forwarding. The OneLogin API Key Vulnerability and the Microsoft OAuth Breach both underline how credential exposure becomes more dangerous when tokens can be replayed beyond their intended context.
For teams standardising controls, the practical rule is simple: scopes answer whether an action is allowed, audience answers whether the caller is allowed to ask this service at all. If either check is missing, the token is too portable for modern API estates.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Token scope and audience are core NHI authorization boundaries. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be constrained to the right service context. |
| NIST SP 800-63 | Token binding and audience checks support stronger digital identity assurance. | |
| NIST Zero Trust (SP 800-207) | Zero trust requires request-time validation of both identity and context. | |
| NIST AI RMF | Autonomous or AI-driven callers need context-aware authorization controls. |
Apply contextual checks so agentic workloads cannot reuse tokens across services.
Related resources from NHI Mgmt Group
- What is the difference between authentication and externalized authorization in API security?
- When is token-based authorization a better fit than static API keys for APIs?
- What is the difference between Phantom Token Flow and Split Token approaches?
- What is the difference between the token handler pattern and putting OAuth tokens directly in a single-page application?
