TL;DR: RFC 8707 adds resource indicators to OAuth 2.0 so tokens are issued for a specific resource server, reducing replay and scope ambiguity in multi-resource environments, according to WorkOS. For IAM teams, the key shift is that audience-bound issuance only works when validation is enforced end to end, not just at the authorization server.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: RFC 8707 resource indicators narrow OAuth token scope for MCP by binding issuance to a declared resource URI and requiring audience checks at the resource server.
Why it matters: It matters because IAM teams designing MCP authorization cannot treat token issuance as enough; validation, cache scoping, and resource registration all have to align or token replay remains possible.
Context
OAuth tokens without an explicit audience boundary can be accepted by more than one resource server, which turns a simple authorization flow into a confused deputy risk. In MCP environments, that problem gets sharper because agents may touch multiple APIs in one session, so token intent has to be clear before issuance.
RFC 8707 addresses that gap by letting the client declare the intended resource at request time and by pushing the authorization server to encode that choice into the token. The practical governance question is whether the receiving resource server enforces the same boundary, because audience-bound issuance only works when validation is symmetrical.
For identity teams, this is not a new authentication model. It is a tighter authorization contract for workloads and AI-driven clients that already rely on OAuth, with direct implications for token replay, scope filtering, and cache design.
Key questions
Q: What breaks when OAuth tokens are not audience-bound in multi-resource environments?
A: Tokens without an explicit resource boundary can be replayed against other APIs that trust the same authorization server, which turns least privilege into an assumption rather than an enforced control. In practice, that creates confused deputy risk, broader-than-intended scope, and cache reuse mistakes across services.
Q: Why do resource indicators reduce replay risk only when APIs validate audience claims?
A: Because the resource parameter only influences issuance. The real enforcement happens when the receiving API compares its expected audience with the token's aud claim and rejects mismatches. Without that validation, the token can still be accepted outside the intended resource boundary.
Q: How should security teams handle token caching in MCP-style multi-resource sessions?
A: They should treat each resource URI as a separate authorization context and cache tokens by resource and scope together. If the cache key ignores the resource, a token issued for one API can be reused incorrectly against another API that happens to share the same issuer.
Q: When should organisations prefer resource-bound OAuth tokens over broad bearer tokens?
A: They should prefer resource-bound tokens whenever a client can call more than one resource server or when scopes are shared across APIs. In those environments, explicit resource targeting is the cleaner way to preserve least privilege and limit unintended token reuse.
Technical breakdown
How resource indicators bind tokens to one resource server
RFC 8707 adds a resource request parameter that identifies the intended resource server as an absolute URI. The authorization server can then mint a token whose audience claim matches that URI and can filter scopes to only those valid for that resource. This narrows token utility from general-purpose bearer material to a token whose accepted use is explicitly declared up front. In practice, the model works best when resource registration, URI stability, and scope mapping are treated as part of authorization design rather than as afterthoughts.
Practical implication: register stable resource URIs and map scopes per resource before enabling audience-bound issuance.
Why audience validation still decides the security outcome
A resource indicator is only half the control. The receiving API must compare its own expected URI with the token's audience and reject mismatches, even if the issuer is trusted and the token is otherwise valid. That validation step is what prevents a token meant for one API from being replayed against another API in the same trust domain. Without it, RFC 8707 becomes a hint to the issuer instead of an enforcement boundary at consumption time.
Practical implication: enforce audience checks in every resource server and do not rely on issuer-side configuration alone.
What changes for MCP clients and token caching
MCP introduces clients, often AI agents, that can interact with many resource servers in one session. That means token caching must be keyed by both resource URI and scope, not just by user or client identity. It also means resource selection becomes part of the access decision path, because the client has to ask for the right token before calling the right API. The operational risk is token reuse across services that trust the same authorization server but should not trust each other's bearer tokens.
Practical implication: scope token caches by resource URI and treat multi-resource MCP sessions as separate authorization contexts.
Threat narrative
Attacker objective: The attacker wants to reuse a valid token against a different resource server and expand access beyond the original authorization intent.
- Entry occurs when a client obtains an OAuth access token that was not explicitly bound to a single resource server, leaving the token usable beyond its intended audience.
- Escalation follows when shared scopes and a common authorization server allow the token to be replayed against a different API that fails to enforce audience checks.
- Impact is unauthorized cross-resource access, where a token issued for one service can be accepted by another service with broader or unintended privileges.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Audience-bound issuance is now a baseline control for multi-resource OAuth. RFC 8707 turns resource targeting into a first-class part of token issuance, which matters whenever a single client may reach more than one API. The old assumption that a bearer token can be broadly accepted inside one trust domain no longer holds in MCP-heavy environments. Practitioners should treat resource indicators as a governance boundary, not just an implementation detail.
Token validation, not token minting, is where the control either survives or fails. A resource parameter only constrains use if the resource server rejects tokens whose audience does not match its own URI. That means the security model depends on both ends of the OAuth exchange, which is why issuer-side support alone does not close confused-deputy risk. Identity teams need to verify the receiving service, not just the authorization server, before considering the design complete.
MCP authorization exposes scope ambiguity as an authorization design flaw, not a protocol quirk. When agents talk to multiple resources in a single session, shared scopes become an access boundary problem rather than a convenience feature. The field should stop treating broad tokens as a reusable default and start treating resource-specific issuance as the normal case for machine and agent clients. The implication is that token intent must be explicit wherever one client can reach many services.
Resource URI stability is an operational dependency, not a minor integration detail. If the URI used at issuance drifts from the URI expected by the API, audience validation breaks and deployments either fail closed or quietly widen acceptance rules. That makes resource registration, cache keying, and URI lifecycle part of access governance. Practitioners should manage resource identifiers with the same discipline they apply to redirect URIs and federation endpoints.
Named concept: audience-bound token boundary. RFC 8707 creates a boundary where the token's intended use is declared at request time and enforced at consumption time. In MCP environments, that boundary is what keeps one agent's authorization context from bleeding into another resource's trust zone. Teams that ignore it are left with a token model that still behaves like a general bearer credential.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
Audience-bound token boundary: The practical shift in OAuth is not just narrower issuance, but a tighter trust boundary between the token issuer and every API that consumes the token. For MCP deployments, that means resource registration, cache design, and audience checks all have to be governed as one control plane rather than separate concerns.
MCP makes token intent a first-order governance problem because agents can traverse many services in one working session. If resource URIs are unstable or audience validation is inconsistent, the result is not merely an integration bug but a reusable credential path that defeats least privilege.
Teams should expect more pressure to document which scopes belong to which resource and to prove that the receiving service enforces the same boundary the issuer declares. That is the line between a token that is merely formatted correctly and a token that is actually constrained.
For practitioners
- Define stable resource URIs Register one absolute URI per resource server or logical API and keep that URI consistent across issuance, validation, and documentation so the aud claim can be matched reliably.
- Enforce audience validation at the API Reject any token whose audience does not match the receiving service, even when the issuer is trusted and the token signature is valid.
- Scope token caches by resource Key cached access tokens on both scope and resource URI so a token issued for one service is never reused against another service in the same session.
- Review scope-to-resource mappings Document which scopes are valid for each declared resource and remove any broad or shared scope mappings that would let a token cross service boundaries.
Key takeaways
- OAuth resource indicators turn token issuance into a resource-specific decision, which is essential when a single client can reach multiple APIs.
- Audience validation at the resource server is the control that makes RFC 8707 effective in practice, not the issuance step alone.
- For MCP and similar multi-resource flows, practitioners need stable resource URIs, resource-scoped caches, and explicit scope-to-resource mappings.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | RFC 8707 tightens token audience handling for non-human clients using OAuth in MCP flows. |
| NHI-05 — Overprivileged NHI | Shared scopes across APIs create overbroad machine access that resource indicators are meant to narrow. | |
| NHI-09 — NHI Reuse | The article warns against reusing bearer tokens across multiple resource servers in one session. | |
| Recommendation — Bind NHI tokens to a declared resource and reject any token that lacks the expected audience. Reduce NHI scope breadth by mapping each token to one resource-specific permission set. Stop reusing access tokens across services and key caches to the token's resource URI. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token issuance, binding, and lifecycle controls sit inside authenticator governance. |
| Recommendation — Apply authenticator management controls to bind, validate, and retire resource-scoped tokens. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centers on ensuring permissions and authorizations stay constrained to the intended resource. |
| Recommendation — Align access permissions to the declared resource and reject tokens that exceed the authorised boundary. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Cross-resource token replay maps to credential abuse followed by movement into another service. |
| Recommendation — Track cross-resource token replay as credential abuse and lateral movement in detection logic. | ||
Key terms
- Resource Indicator: A resource indicator is a request-time signal in OAuth that tells the authorization server which resource server the token is meant for. In practice, it helps constrain the resulting token audience so access is tied to one API or logical service instead of being broadly reusable.
- Audience Claim: The audience claim is the value inside a token that identifies who or what should accept it. For non-human identity governance, it is the enforcement point that prevents a token issued for one resource from being accepted by another resource with a different trust boundary.
- Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
- Resource-scoped Token Cache: A resource-scoped token cache stores access tokens by both scope and intended resource server. This prevents a client from reusing a valid token against another API that shares the same issuer but not the same authorization boundary.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 4, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org