MCP OAuth discovery: when authentication metadata becomes an SSRF pivot

A hypothetical, but familiarIn a hypothetical onboarding session, an engineer connects a hosted agent to a new MCP server and waits for a sign-in prompt. Instead, the agent’s OAuth client uses an advertised metadata URL to request a service on its own internal network. No token exists yet, but the outbound request has already crossed the boundary.

The network boundary is crossed before a token exists

The MCP security guidance identifies an SSRF path through OAuth discovery: a malicious server can control the resource_metadata URL in WWW-Authenticate, the authorization_servers values in protected-resource metadata, and endpoint URLs in authorisation-server metadata. The vulnerable behaviour is not accepting a bad token; it is making an HTTP request to an unintended destination. That destination might be an internal service, a localhost listener or a cloud metadata endpoint. The request uses the client’s network position, which may expose services the malicious MCP server cannot reach directly.

AWS documents a legitimate discovery sequence for its MCP Server: the agent retrieves RFC 9728 protected-resource metadata, retrieves RFC 8414 AWS Sign-In metadata, dynamically registers, and initiates the authorisation code flow. Tokens follow successful authorisation. This illustrates why discovery deserves its own security review; it is not evidence of an AWS vulnerability. My recommendation is to review outbound discovery permissions separately from token permissions, because controls applied only after token issuance do not govern those earlier requests.

Evidence: Introducing OAuth Support for AWS MCP Server, Security Best Practices

The two RFCs describe a discovery chain, not destination approval

RFC 9728 publishes protected-resource metadata at a well-known location derived from the resource identifier; it also describes advertising a metadata URL through WWW-Authenticate. Its required resource value identifies the protected resource, while optional authorization_servers entries identify OAuth issuers, not token endpoints. RFC 8414 then supplies metadata from a well-known location derived from an issuer, including authorisation, token and optional registration endpoints. Its issuer identifier uses HTTPS and has no query or fragment. These structures describe service relationships; my recommendation is not to treat them as permission to contact whatever destination they name.

OAuth discovery is an outbound network privilege, not a harmless prelude to authentication, and every metadata-derived destination needs an explicit policy decision before connection.

Evidence: RFC 9728, Security Best Practices, OAuth 2.0 Authorization Server Metadata

Approve destinations explicitly rather than trusting the MCP server

OWASP distinguishes applications that contact identified, trusted services from applications that must reach arbitrary external destinations. For enterprise MCP integrations, I recommend making the first model the default: approve the resource, metadata location, issuer and required endpoints through configuration or review. An untrusted server must not expand that approval merely by returning another URL. A hostname allowlist is only one layer. OWASP explicitly warns that domain allowlisting alone does not prevent DNS rebinding, so destination policy must also cover resolved addresses.

• Maintain approved discovery destinations and issuer relationships outside server-supplied metadata.
• Use strict matching for approved hostnames rather than permissive suffix rules.
• Require HTTPS for discovery requests and reject unexpected schemes.
• Validate resolved IPv4 and IPv6 addresses against permitted networks before connecting.
• For public integrations, deny private, loopback and link-local destinations by default.
• Approve any necessary internal identity service narrowly, rather than permitting private networks wholesale.

Evidence: Server-Side Request Forgery Prevention Cheat Sheet¶, Security Best Practices

Validate the address the client actually connects to

The critical check sits between resolution and connection. OWASP says to validate resolved destination addresses against permitted networks and ensure the HTTP client connects only to validated addresses. A second, unchecked DNS lookup can defeat an earlier check. The connection mechanism must preserve the original hostname for the HTTP Host header, TLS Server Name Indication and certificate verification while using the validated address. Apply the same destination policy to retries and fallback connections; checking only the first attempted connection leaves another route around the control.

OWASP recommends disabling redirect following to prevent input-validation bypasses. I would keep automatic redirects disabled for discovery. If a required integration needs redirects, my recommendation is to handle them explicitly: validate each new URL, check its approval, resolve its hostname, enforce the address policy and connect only to a validated result. Do this before following every hop, not after receiving the final response. An approved starting URL does not approve the redirect destination, even when the first response arrives over HTTPS.

Evidence: Introducing OAuth Support for AWS MCP Server, Server-Side Request Forgery Prevention Cheat Sheet¶

Test denied connections, not just rejected metadata

I recommend exercising the complete discovery client with controlled metadata documents and test listeners from the environment where the agent runs. A parser-only test cannot demonstrate that redirects, DNS resolution or HTTP retries obey the policy. Put rejected destinations into both the advertised metadata location and later issuer or endpoint fields. Do not assume every endpoint is fetched during discovery: test each when the client actually uses it. Use simulated cloud metadata responses rather than probing live credential endpoints.

For acceptance, require evidence that the forbidden destination receives no connection, not merely that the client eventually reports an OAuth error. I also recommend recording the discovery stage, proposed hostname, resolved addresses and policy decision so failures are diagnosable. Pair application checks with network-layer restrictions, as OWASP advises for defence in depth. The practical boundary is simple: metadata can propose the next service, but only locally enforced policy can authorise the next connection.

Evidence: Server-Side Request Forgery Prevention Cheat Sheet¶, Security Best Practices