MCP OAuth Token Audience Checklist

Overview

Remote MCP servers are convenient because the client can connect to a hosted endpoint instead of launching a local process. They also move trust into a networked authorization flow. The MCP authorization specification is explicit: HTTP-based transports should use OAuth 2.1-style flows, protected resource metadata, authorization server metadata, resource indicators, bearer tokens, and token audience validation.

This checklist is for maintainers and operators reviewing a remote MCP server before connecting it to an AI client. It is intentionally practical: each item is something you can verify from docs, metadata, client config, or a small test.

Review Checklist

Endpoint and transport

• The endpoint uses HTTPS.
• The server clearly identifies whether it uses Streamable HTTP, stdio, or a custom transport.
• Client setup does not place bearer tokens in query strings.
• The endpoint path is stable enough to serve as a resource identifier.

Discovery and client registration

• The server documents where OAuth metadata is discovered.
• The authorization server supports appropriate OAuth metadata.
• Dynamic client registration is supported or the docs explain the alternative.
• Redirect URI handling is exact and does not allow open redirects.

Resource indicators and audience

• Authorization and token requests include a resource value for the target MCP server.
• Tokens are audience-bound to the MCP server that will receive them.
• The MCP server rejects tokens issued for another resource.
• The server does not pass the client token through to unrelated downstream APIs.

Token storage and logging

• Client config stores secrets in environment variables, secure keychain storage, or an approved credential store.
• Logs redact bearer tokens, authorization codes, and refresh tokens.
• Error messages do not echo tokens or private resource identifiers.
• Access tokens are short-lived where the authorization server supports it.

Tool risk

• Tool names and descriptions are clear enough for a model to use correctly.
• Write or delete tools require explicit user approval or narrower scopes.
• Tools that return private data document the data class they can expose.
• Rate limits and timeout behavior are visible in docs or error responses.

Red Flags

Troubleshooting

The client receives 401 responses

Confirm the MCP server advertises protected resource metadata and that the client can parse WWW-Authenticate. Check whether the token request included the same resource URI the server expects.

The server accepts a token from another audience

Treat this as a blocking security issue. Audience validation is the core control that prevents cross-service token reuse.

Docs recommend a URL with the token embedded

Prefer a header-based or environment-backed configuration. If that is impossible, use the server only for low-sensitivity data until the provider supports safer credential handling.

Duplicate Check

Existing MCP security content covers least privilege and threat modeling. This entry focuses specifically on OAuth, resource indicators, audience binding, and remote MCP token handling.

References

• MCP authorization specification - https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
• MCP transports specification - https://modelcontextprotocol.io/specification/2025-06-18/basic/transports
• MCP tools specification - https://modelcontextprotocol.io/specification/2025-06-18/server/tools
• MCP introduction - https://modelcontextprotocol.io/docs/getting-started/intro