Notifications
Clear all
Topic starter
01/07/2026 2:11 am
TL;DR: OAuth resource indicators let MCP clients bind access tokens to a specific server audience, reducing token reuse and confused deputy risk in multi-server agent workflows, according to WorkOS. The deeper issue is that broad, reusable tokens weaken least privilege unless audience validation is enforced end to end.
NHIMG editorial — based on content published by WorkOS: How to secure your MCP server with OAuth resource indicators
By the numbers:
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: How should security teams implement audience-bound tokens for MCP servers?
A: Security teams should bind each token to a single MCP server, validate the aud claim at the resource server, and make clients request the same resource URI during authorization and token exchange.
Q: Why do MCP environments need resource indicators if OAuth scopes already exist?
A: Scopes limit what a token can do, but they do not say where that token may be used.
Q: What breaks when MCP tokens are accepted without audience checks?
A: Without audience checks, a token can become a reusable credential across multiple servers that trust the same authorization authority.
Practitioner guidance
- Enforce audience validation on every MCP server Configure resource servers to reject tokens whose aud claim does not exactly match the server's canonical resource URI, and test both valid and invalid audience cases before production.
- Require the resource parameter in both auth steps Make clients send the resource parameter during authorization and token exchange so the authorization server issues a token that is explicitly bound to the intended MCP server.
- Standardise canonical resource URIs Publish one exact URI format for each MCP server and use it consistently in metadata, client configuration, token issuance, and validation to avoid mismatches caused by trailing slashes or scheme drift.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step OAuth request examples showing how the resource parameter maps to the aud claim in MCP flows
- Server-side implementation guidance for validating audience values and handling invalid_token responses
- Client and authorization-server configuration details for supporting multiple MCP servers safely
- Common URI canonicalization pitfalls and compatibility notes for RFC 8707 support
👉 Read WorkOS's guide to securing MCP servers with OAuth resource indicators →
MCP server token audience binding: what IAM teams need to know?
Explore further
01/07/2026 2:33 am
Audience-bound tokens are now a baseline control for MCP, not an advanced option. MCP environments are inherently multi-server, so a bearer token without resource binding is structurally too broad for the trust model the protocol creates. The governance question is no longer whether OAuth works, but whether the token lifecycle preserves a server-specific boundary from issuance to acceptance. Practitioners should treat audience validation as the minimum viable control for MCP deployments.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
A question worth separating out:
Q: Who is accountable if an MCP server accepts the wrong audience token?
A: Accountability sits with both the authorization server operator and the MCP server operator. The issuer must bind tokens to the correct resource URI, and the resource server must reject mismatched tokens. If either side skips that control, the boundary fails and the resulting access is not defensible.
👉 Read our full editorial: OAuth resource indicators harden MCP server token audience binding
