This site is an MCP server

              served at https://app.example.com/oauth/client-metadata.json
{ "client_id": "https://app.example.com/oauth/client-metadata.json",
  "client_name": "Example MCP Client",
  "redirect_uris": ["http://127.0.0.1:3000/callback"],
  "token_endpoint_auth_method": "none" }
            

There is no registration CALL. The URL the document is served from IS the client_id, and the two must match exactly — an authorization server is required to reject a document whose client_id disagrees with its own URL. The URL must be https and carry a path component.

TWO INDEPENDENT CHOICES, easy to conflate. How a client gets its identity (CIMD vs DCR vs pre-registration) is separate from which grant it then uses (authorization code vs client credentials) — swapping DCR for CIMD does not turn a machine-to-machine integration into a user-consent one. This diagram shows authorization code because a human is present to consent, which is the common MCP client case; the legacy diagram below happens to show client credentials. Either registration mechanism can front either grant.

The flow starts at the resource, not the authorization server — which is why the client needs no prior knowledge of either.

              HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer
  resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
  scope="tools.read"
            

This is where the `resource` value used below comes from: the client fetches that Protected Resource Metadata document (RFC 9728, a MUST for MCP servers) to learn the server's canonical URI and which authorization server to talk to. The advertised `scope` is authoritative for this request — request that, not everything.

              GET /authorize?
  response_type=code
  &client_id=https://app.example.com/oauth/client-metadata.json
  &redirect_uri=http://127.0.0.1:3000/callback
  &code_challenge=…&code_challenge_method=S256
  &scope=tools.read
  &resource=https%3A%2F%2Fmcp.example.com
            

`scope` is the one the 401 already told you: the challenged scope is authoritative for this request, so ask for exactly it rather than the server's defaults — too little and the original call still fails, too much and least privilege was decorative. `resource` is the one people leave out entirely. MCP requires RFC 8707 resource indicators on BOTH this request and the token request, naming the canonical URI of the MCP server — that is what binds the resulting token to one audience, so a token minted for another server cannot be replayed against this one. Clients must send it whether or not the authorization server supports it. PKCE because this is a public client holding no secret; check the server advertises `client_id_metadata_document_supported: true` first, since CIMD cannot be adopted unilaterally.

The authorization server sees a URL-formatted client_id and resolves it. This replaces the registration table: nothing was stored ahead of time, and nothing needs to be.

Cached per the document's HTTP cache headers. That TTL is now part of the security model — it bounds how long revoked or altered metadata is still honoured.

The consent screen shows `client_name` from a document the client controls. Whoever controls the hostname controls how the client presents itself — the trade CIMD makes in exchange for needing no registration.

The authorization server validates the redirect_uri against the list in the fetched document before honouring it.

              302 → http://127.0.0.1:3000/callback?code=…&iss=https://auth.example.com
            

2026-07-28 also asks authorization servers to send `iss` (RFC 9207), and requires clients to validate it against the recorded issuer before redeeming the code.

              POST /token
grant_type=authorization_code&code=…&code_verifier=…
&redirect_uri=http://127.0.0.1:3000/callback
&client_id=https://app.example.com/oauth/client-metadata.json
&resource=https%3A%2F%2Fmcp.example.com
            

`resource` again, identical to the authorization request — omitting it here is the subtler half of the same mistake, and costs the audience binding even though the first request looked correct. `redirect_uri` must be repeated because it was in the authorization request. No client secret: the PKCE verifier is what proves this is the same client that started the flow. A confidential client may instead authenticate with `private_key_jwt` via JWKS.

The identity is portable: because the client_id is a self-hosted URL any authorization server can resolve, moving to a different authorization server needs no re-registration — where DCR credentials are bound to their issuer and must be re-registered.

              POST /mcp
Authorization: Bearer …
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: <tool>

{ "jsonrpc": "2.0", "id": 1,
  "method": "tools/call",
  "params": { "name": "<tool>", "arguments": {} },
  "_meta": {
    "io.modelcontextprotocol/protocolVersion": "2026-07-28",
    "io.modelcontextprotocol/clientCapabilities": {}
  } }
            

The authorization header is the part this diagram is about, but the rest is not optional and is easy to drop when copying: 2026-07-28 is stateless, so EVERY request carries its own protocol version and client capabilities in `_meta`, alongside the `MCP-Protocol-Version` header and the `Mcp-Method` / `Mcp-Name` routing headers. A conforming server can reject the request on those before it ever evaluates the token.

The MCP server verifies the token and decides; the client does not assert its own authority. A refusal is a normal outcome — least privilege only means something if the denial path is exercised.

              POST /register
{ "software_id": "…", "software_version": "…" }
            

Historically RFC 7591 Dynamic Client Registration. Note that MCP revision 2026-07-28 DEPRECATED DCR in favour of Client ID Metadata Documents — new builds should not reach for it, and this step is the one that changes first.

              201 Created
{ "client_id": "…",
  "client_secret": "…",
  "registration_access_token": "…" }
            

Two DIFFERENT credentials, and conflating them is a common bug: `client_secret` authenticates the client at the TOKEN endpoint, while `registration_access_token` only manages this registration (RFC 7592) and can never be exchanged for an access token. A public client gets no secret at all — it uses the authorization-code flow with PKCE and does not authenticate itself. `private_key_jwt` is the other option for a CONFIDENTIAL client, replacing the shared secret with a signed assertion.

The agent never mints its own identity — it receives one. That separation is what makes the audit trail meaningful later. The registration access token stays with the orchestrator; the agent has no reason to hold it.

              POST /token
Authorization: Basic base64(client_id:client_secret)
grant_type=client_credentials&scope=tools.read
&resource=https%3A%2F%2Fmcp.example.com
            

`client_secret_basic` shown for brevity; `private_key_jwt` is the stronger option and avoids a shared secret entirely. Scopes are requested narrowly, per task — not "everything this agent might ever need".

Short TTL so a leaked token expires before it is useful, and rotation is routine rather than an incident.

              Authorization: Bearer …
{ "method": "tools/call", "params": { "name": "…" } }
            

Introspection or local JWKS verification. The MCP server decides; the agent does not assert its own authority.

A refusal is a normal outcome, not an error condition — least privilege only means something if the denial path is exercised.

Which client_id reached which tool, under which scope, when. This is the question an auditor actually asks, and the reason the identity is per-client rather than shared.