createmcps.com

Error

MCP OAuth: authorization server metadata not found

Against MCP 2026-07-28 · verified 10 August 2026

The chain gets one link further than a missing resource document and then stops. The client found your authorization server's identifier and went looking for its metadata; neither well-known path answered.

The error

exposes neither RFC 8414 nor OpenID Connect Discovery metadata
How often we see this:

2 of the 16 real MCP servers we probed on 2026-08-11 tripped MCP-AUT-004. That is a snapshot of hand-picked public servers, not a random sample of the ecosystem — it shows the failure is common in practice, not that a given percentage of all servers have it.

What causes it

Discovery is a chain: the 401 names a Protected Resource Metadata document, that document names an authorization server, and the client then fetches that server's metadata to learn where to send the user and where to redeem the code. Break any link and the flow stops.

There are two conventional paths, and clients try both: RFC 8414's `/.well-known/oauth-authorization-server` and OpenID Connect Discovery's `/.well-known/openid-configuration`. Publishing neither means a client cannot proceed even though every other part of your setup is correct.

The most common real cause is not a missing document but a path assembled wrongly. RFC 8414 inserts the well-known segment BEFORE any path component of the issuer, which is the opposite of what most people expect — for issuer `https://auth.example.com/tenant1` the document lives at `https://auth.example.com/.well-known/oauth-authorization-server/tenant1`.

How to fix it

The fix

Confirm which paths your provider actually servesFetch both well-known URLs directly with no credentials. Most commercial identity providers publish OpenID Connect Discovery; some publish RFC 8414 as well. You only need one, but you need it at the URL a client will construct.

The fix

Build the RFC 8414 path correctly for a path-bearing issuerThe well-known segment goes between the host and the issuer's path, not after it. Getting this backwards produces a 404 that looks like a missing document.
Issuer with a path component
issuer:  https://auth.example.com/tenant1

RFC 8414:
  https://auth.example.com/.well-known/oauth-authorization-server/tenant1

OpenID Connect Discovery:
  https://auth.example.com/tenant1/.well-known/openid-configuration

The fix

Check the issuer value matches exactlyThe `issuer` in the discovery document must equal the identifier your resource metadata named — byte for byte, including any trailing slash. A mismatch is a security check working correctly, and clients are required to reject it.

The fix

While you are there, check the 2026-07-28 additionsThis revision expects authorization servers to advertise `authorization_response_iss_parameter_supported` (RFC 9207), and increasingly `client_id_metadata_document_supported`. Neither blocks the flow, but the first closes a real authorization-server mix-up vulnerability.

Rules involved

Each of these is checked against a live server, and each links to the exact sentence of the specification it comes from.

RuleWhat we checkLevelIf it fails
MCP-AUT-004Each listed authorization server exposes RFC 8414 or OIDC discovery metadataMUSTfail
MCP-AUT-005AS advertises authorization_response_iss_parameter_supported: trueSHOULDwarn
MCP-AUT-011AS supports Client ID Metadata Documents, not DCR aloneSHOULDwarn

FAQ

Frequently asked

Where should authorization server metadata be published?

At /.well-known/oauth-authorization-server (RFC 8414) or /.well-known/openid-configuration (OpenID Connect Discovery). Clients try both, so publishing either is enough — but it must be at the URL a client actually constructs from your issuer identifier.

Why does discovery 404 when my issuer has a path?

Because RFC 8414 puts the well-known segment before the issuer's path, not after it. For issuer https://auth.example.com/tenant1 the document is at https://auth.example.com/.well-known/oauth-authorization-server/tenant1. OpenID Connect Discovery does the opposite and appends, which is why the same issuer has two different-looking URLs.

Does the issuer in the document have to match exactly?

Yes, byte for byte, including any trailing slash. Clients are required to reject a mismatch — it is the check that stops one authorization server impersonating another, so a lenient client would be the bug.

Check this against your own server

Point the validator at a live MCP server and it reports every rule on this page as pass, warn or fail — each linked to the exact spec sentence it comes from.

Validate a server →