skip to content

How does an MCP client discover which authorization server protects a remote MCP server?

level: middleimportance: must knowfreq 68%

answer

  1. Metadata document, not a header
  2. A well-known path on the resource
  3. RFC 9728 names the field
  4. The 401 hint is optional now
  5. authorization_servers, then issuer metadata

basics

~20 s

Through RFC 9728 protected-resource metadata. The client fetches the document at the MCP server's /.well-known/oauth-protected-resource path and reads its authorization_servers field. A 401 may point there with WWW-Authenticate, but that challenge is optional, so the well-known fallback is mandatory.

solid answer

~40 s

A remote MCP server publishes **RFC 9728 protected-resource metadata**, a JSON document served from `/.well-known/oauth-protected-resource` derived from the server's URL. Its `authorization_servers` field names the issuer(s) whose tokens the server accepts; the client then fetches that issuer's own authorization-server metadata to find the authorization and token endpoints. When a request arrives unauthenticated, the server may answer `401` with a `WWW-Authenticate: Bearer` challenge carrying a `resource_metadata` parameter that points straight at the document — but in MCP revision 2026-07-28 that challenge is **optional**, and a client MUST be able to fall back to the well-known path on its own. Building a client that only discovers the authorization server when a challenge header appears is the classic bug: against a conformant server that omits the header, it simply fails.

code

http · 3 lines
http
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"
Content-Length: 0

go deeper

for a junior

Know that the client does not guess where to log in: it reads a metadata document published by the MCP server at a well-known path and finds the authorization server named there.

for a middle

Be able to name RFC 9728, the /.well-known/oauth-protected-resource path and the authorization_servers field, and to explain the second hop to the authorization server's own metadata for the endpoints.

for a senior

Emphasize that the WWW-Authenticate challenge became optional in 2026-07-28, so a client built around challenge-driven discovery breaks in the field. Talk about caching discovery results by server identity now that there is no session to hang them on.

for a principal

Own the trust policy: authorization_servers is self-asserted by the resource, so decide as an organization which issuers your host is willing to start a user flow against, and how server URLs get vetted before anyone pastes one in.

## The problem discovery solves An MCP client is handed a URL for a remote server and nothing else. Before it can obtain a token it must learn two things: which authorization server is allowed to mint tokens for this resource, and what identifier that resource goes by so the token can be bound to it. Hardcoding either would make MCP servers non-portable, so the specification borrows an existing standard instead of inventing one. ## RFC 9728 protected-resource metadata RFC 9728 defines a metadata document that a protected resource publishes about itself. In MCP revision 2026-07-28, a remote server publishes such a document at the `.well-known` path `/.well-known/oauth-protected-resource`, derived from the MCP server's URL. Two fields matter most: - `resource` — the canonical URI identifying this MCP server. This is the value the client will later use to ask for an audience-bound token. - `authorization_servers` — an array of issuer identifiers whose tokens this server will accept. The client picks an issuer from that array and fetches *that* server's authorization-server metadata, which is where the authorization endpoint, the token endpoint and the supported PKCE methods live. So discovery is two hops: resource metadata to find the issuer, issuer metadata to find the endpoints. ## The challenge, and why it is only a hint RFC 9728 also defines a `resource_metadata` parameter for the `WWW-Authenticate: Bearer` challenge, so an unauthenticated request can be answered with a `401` that points directly at the metadata document. Earlier MCP revisions leaned on that challenge as the discovery trigger. Revision 2026-07-28 changed the emphasis: the `WWW-Authenticate` challenge is now **optional**, with a mandated `.well-known` fallback. A conformant server may reject an unauthenticated request without telling the client anything about where to authenticate. The consequence for client authors is concrete — treat the challenge as an optimization that saves a probe when present, and always implement construction of the well-known URL from the server URL as the path that must work. This is a common interview trap because so much material written before mid-2026 describes challenge-driven discovery as *the* mechanism. A candidate who says "the server tells you in the 401" and stops has described a client that breaks against half the fleet. ## Why not just configure the authorization server by hand? Operators do sometimes preconfigure it, and nothing forbids that. But an MCP client is typically a general-purpose host that connects to servers the user adds at runtime. Discovery makes adding a server a matter of pasting a URL, which is the entire point of a portable protocol. It also lets a server change identity providers without every client being reconfigured. ## What the client must not infer Discovery tells the client where to authenticate. It does not tell it whether the server is trustworthy — a metadata document is self-asserted, just like `serverInfo`. And discovery is not part of MCP's own protocol surface: it happens at the HTTP/OAuth layer before or around MCP requests, and it is not tied to any MCP method, connection, or handshake. There is no session in 2026-07-28 to attach the result to, so a client caches its token and its discovery results by server identity, not by connection. ## Failure modes worth naming - **Challenge-only clients.** As above: no header, no discovery, dead client. - **Trusting an arbitrary issuer.** The `authorization_servers` array comes from the resource itself; a client that will initiate a flow against *any* issuer named there, without a policy about which issuers it is willing to send a user to, has widened its trust surface. - **Skipping the second hop.** The issuer identifier is not the token endpoint. The client must fetch the authorization server's own metadata rather than guessing endpoint paths. - **Losing the `resource` value.** The canonical resource identifier discovered here is exactly what the client will send as the RFC 8707 `resource` parameter to get an audience-bound token. Dropping it produces a token that a well-behaved MCP server should refuse. ## The shape of a working flow Request without a token, or go straight to discovery. Fetch `/.well-known/oauth-protected-resource`. Read `resource` and `authorization_servers`. Fetch the chosen issuer's metadata. Verify PKCE support. Run the authorization code flow with PKCE, passing `resource`. Attach the resulting token to every subsequent MCP request.

  • Once the client has the issuer identifier, what does it fetch next?
    The authorization server's own metadata document, which advertises the authorization endpoint, the token endpoint and the supported PKCE challenge methods. The `authorization_servers` entry in the resource metadata is an issuer identifier, not an endpoint, so discovery is two hops: resource metadata for the issuer, issuer metadata for the endpoints.
  • Why did MCP 2026-07-28 make the WWW-Authenticate challenge optional?
    Because relying on a challenge makes discovery depend on first making a request that fails, and on infrastructure — proxies, gateways, CDNs — preserving a response header. Mandating the `.well-known` fallback gives clients a deterministic path that works without a failed probe. The challenge remains useful as an optimization when a server does send it.
  • Is the protected-resource metadata document itself trustworthy?
    Only as far as the transport is. It is served over HTTPS from the resource's own origin, so it authenticates as coming from that host, but its contents are self-asserted: the server names the issuers it claims to trust. A client should still apply its own policy about which authorization servers it is willing to send a user to.

saying these in an interview costs you the question

  • Says discovery only happens via the 401 challenge header
  • Treats the issuer identifier as the token endpoint
  • Guesses OAuth endpoint paths instead of fetching metadata
  • Discards the canonical resource identifier from the metadata
  • Assumes discovery is an MCP protocol method

context

resolving links…