OAuth Resource Indicators bind a token request to a specific resource server. In MCP, they help ensure the access token is meant for the intended server and reduce token replay across services. They support authentication and audience binding, but they do not make the final fine-grained authorization decision.
Expanded Definition
OAuth Resource Indicators are a request-time signal that binds an access token to a particular resource server, so the authorization server can issue a token intended for one audience rather than a generic bearer credential. In NHI and agentic AI environments, that distinction matters because agents, service accounts, and integrations often call multiple APIs, and token reuse across services can become a hidden blast-radius problem. The core idea is audience binding, but implementations vary across vendors and deployment patterns, especially when multiple resource servers sit behind gateways or when an AI agent brokers requests on behalf of several tools. The IETF Resource Indicators for OAuth 2.0 draft formalises this pattern, while NIST SP 800-53 Rev 5 Security and Privacy Controls provides the broader control expectations for access enforcement and token handling. The most common misapplication is treating resource indicators as an authorization policy, which occurs when teams assume the bound token alone can decide scope, role, or per-record access.
Examples and Use Cases
Implementing OAuth Resource Indicators rigorously often introduces more client and authorization-server coordination, requiring organisations to weigh tighter audience control against added integration complexity.
- An MCP client requests a token for only one backend tool server, preventing that token from being replayed against a different service with broader permissions.
- A service account used by an agentic workflow accesses both billing and support APIs, but receives separate tokens bound to each resource server instead of a shared bearer token.
- A third-party OAuth app is constrained to a specific internal resource, reducing exposure if the app is later abused or its refresh flow is compromised, as seen in the Klue OAuth Supply Chain Breach.
- Security teams compare token audience claims against the intended API during review, then validate the surrounding access rules with guidance from OAuth 2.0 and adjacent token-binding patterns.
- Operational teams use resource indicators alongside gateway policies so a token issued for one environment, tenant, or cluster cannot silently cross into another.
In practice, the term is most useful when the same identity can reach multiple resources but should never carry a single all-purpose token. That is why incidents like the Salesloft OAuth token breach are so instructive: the problem is not only token theft, but the opportunity for that token to be accepted beyond its intended audience.
Why It Matters in NHI Security
OAuth Resource Indicators reduce the chance that a stolen or over-broad token becomes a reusable credential across services, which is a major NHI security concern because service accounts and agents often operate at machine speed and at scale. NHIMG research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, making audience restrictions especially valuable when external integrations are part of the trust chain. When resource binding is absent, teams may unintentionally create a single credential path that can pivot from one API to another, undermining least privilege and complicating incident response. This is especially relevant where APIs front sensitive workflows, because token misuse can look like legitimate traffic until audit logs are correlated by resource and issuer. Resource indicators do not replace authorization, secrets hygiene, or rotation, but they make replay and lateral movement harder by narrowing what a token can legitimately reach. The same risk pattern is visible in the Dropbox Sign breach and the Microsoft OAuth Breach, where OAuth abuse becomes dangerous once trust is too broad. Organisations typically encounter the operational impact only after a token is stolen, replayed, or discovered in logs, at which point resource binding becomes unavoidable to address.
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 Zero Trust (SP 800-207), NIST SP 800-63 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-03 | Token audience binding limits cross-service replay of NHI credentials. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access depends on constraining which resource a token can reach. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust requires explicit validation of each requested resource, not shared trust across APIs. |
| NIST SP 800-63 | Digital identity assurance informs how strongly a token is bound to a particular relying party. | |
| NIST AI RMF | GOV 3.3 | AI systems need governance over access boundaries for tools and connected resources. |
Document which agent or client may request tokens for each resource and review those mappings regularly.
