Notifications
Clear all
Topic starter
04/06/2026 6:48 pm
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.
NHIMG editorial — based on content published by WorkOS: Resource Indicators in OAuth 2.0, a guide to RFC 8707 and audience-bound tokens for secure MCP authorization
Questions worth separating out
Q: How should security teams handle OAuth tokens in multi-resource environments?
A: Security teams should bind OAuth tokens to a specific resource server and enforce audience validation at the point of use.
Q: Why do audience-bound tokens matter for MCP authorization?
A: MCP clients can move across multiple resource servers in a single session, so generic tokens create replay risk and scope ambiguity.
Q: What do IAM teams get wrong about OAuth resource indicators?
A: Teams often assume that correct token issuance is enough.
Practitioner guidance
- Bind each token to a single resource URI Require authorization requests to include a resource parameter and verify that the resulting aud claim matches the intended API.
- Enforce audience validation at every API Configure each resource server to reject tokens whose aud value does not match its own URI, even when the token was issued by a trusted authorization server.
- Partition token caches by audience Key client-side token caches on both scopes and resource URI so a token issued for one API cannot be silently reused against another.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step RFC 8707 request and response examples for resource-bound token issuance.
- Practical guidance on how authorization servers map scopes to specific resource URIs.
- Implementation details for audience validation and token caching in MCP-style integrations.
- Configuration considerations for WorkOS AuthKit and MCP Auth deployments.
👉 Read WorkOS's guide to RFC 8707 and secure MCP authorization →
RFC 8707 and MCP authorization: are your tokens audience-bound?
Explore further
04/06/2026 7:01 pm
Audience-bound tokens are now a governance requirement, not a nice-to-have protocol detail. RFC 8707 addresses a structural weakness in OAuth deployments where one token can become valid for more than one resource server. That weakness is easy to overlook in traditional app-to-API patterns, but it becomes much more dangerous in multi-resource and MCP environments. The practitioner conclusion is straightforward: token audience is part of access governance, not just implementation plumbing.
A few things that frame the scale:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means many teams still lack the inventory needed to enforce token audience boundaries consistently.
A question worth separating out:
Q: How can organisations prevent confused deputy problems in API access?
A: Organisations should make resource identity explicit everywhere a token is issued or consumed. Use resource-specific scopes, validate the aud claim, and avoid shared token pools across unrelated services. That combination limits unintended cross-API access and makes misuse easier to detect.
👉 Read our full editorial: Resource indicators in OAuth 2.0 tighten MCP token boundaries
