EN

中文

EN

中文

Appearance

Go to Dashboard
中文

🚧 Roadmap — The capability described here is on the roadmap. The concepts and design are settled; interfaces and steps are subject to the final release.

Add authorization to your MCP server ​

The MCP specification (2025-06-18) positions an MCP server squarely as an OAuth 2.1 resource server, and requires the authorization server to live outside it: an MCP server does not issue tokens, does not manage users, and does not run consent. The spec assumes you already have a proper authorization server. GenAuth is that authorization server.

This was not always the position. The 2025-03 spec allowed an MCP server to double as its own authorization server; community practice ruled that path out, and the 2025-06-18 spec formally split resource server from authorization server. "A separate, purpose-built authorization server" went from optional to the spec's default assumption.

For Agent Identity there is a second implication: behind an MCP client there is usually an agent. Routing authorization through GenAuth pulls MCP tool calls into the delegation model — every token can answer who authorized it, on whose behalf it acts, and what it may do, and every token is auditable and revocable.

The authorization flow: 8 steps, one responsible party each ​

What follows is the conceptual flow, aligned step by step with the authorization chapter of the MCP spec. GenAuth's own endpoints and registration entry points are subject to the final release; this page invents nothing.

Prerequisite · Register the protected resource (responsible: your app × GenAuth) Declare the MCP server as a protected resource in GenAuth and define the scope vocabulary it exposes. Every "authorization scope" in the steps below is expressed in that vocabulary.

1 · A request with no token; the 401 hands out the clue (responsible: MCP server ｜ RFC 9728) The MCP client's first call carries no access token, or an invalid one. The MCP server returns 401 Unauthorized and uses the WWW-Authenticate header to point at the location of its protected resource metadata.

2 · Discover the authorization server (responsible: MCP client ｜ RFC 9728) The MCP client reads the protected resource metadata and learns which authorization server this MCP server trusts — GenAuth.

3 · Read the authorization server metadata (responsible: MCP client, metadata served by GenAuth ｜ RFC 8414) The MCP client fetches GenAuth's authorization server metadata: authorization endpoint, token endpoint, and supported capability declarations — every entry point the rest of the flow needs.

4 · Register dynamically as an OAuth client (responsible: MCP client × GenAuth ｜ RFC 7591) The MCP client dynamically registers as an OAuth client of GenAuth. The spec recommends (SHOULD) supporting dynamic registration so clients can onboard with no human in the loop; deployments that do not support it can fall back to pre-registration.

5 · Authorization code + PKCE; a human completes consent (responsible: MCP client initiates × GenAuth hosts ｜ OAuth 2.1, PKCE required) The MCP client starts the authorization code flow, and the user — or an organization administrator, see Consent and approval — completes consent on GenAuth's consent screen. This is where the delegation worldview lands: the scopes on that screen are the exact slice of authority a person explicitly hands over. PKCE is mandatory in OAuth 2.1 (absorbed from RFC 7636) and blocks authorization code injection.

6 · Trade the code for a token, with the audience nailed down (responsible: MCP client × GenAuth ｜ OAuth 2.1 + RFC 8707) The MCP client exchanges the authorization code for an access token. The spec requires declaring the token's target resource with the resource parameter (RFC 8707) — the token is bound to this one MCP server and is worthless anywhere else, which shuts down token misuse at the issuance side.

7 · Call with the token; the resource side validates (responsible: MCP server) The MCP client calls tools with the access token. As a resource server, the MCP server validates signature, audience, and scope, and admits only calls inside the authorized range. The spec's security considerations explicitly forbid token passthrough — an MCP server must not forward a token it received to a downstream service to reuse, which is the classic entry point for a confused deputy (see also Security considerations). For the general resource-side checklist, see Protect your APIs.

8 · Downstream access, evidence, and taking authority back (responsible: MCP server × your app × GenAuth) When the MCP server needs to reach your app or a downstream resource, it requests a downstream token on demand from its own restricted context (for delegation and exchange semantics, see Delegate Token and attenuation) rather than passing the upstream token through. Every call stays on the audit chain (Audit and accountability chain), and if something goes wrong you pull authority back with the kill switch described in Revocation and emergency response.

The standards in one table ​

Stage of the flowStandardWhat it governs
Resource metadata and AS discovery (steps 1–2)RFC 9728How an MCP server declares "here is my authorization server"
Authorization server metadata (step 3)RFC 8414How a client discovers GenAuth's endpoints and capabilities
Dynamic client registration (step 4)RFC 7591Client onboarding with no human in the loop
Authorization code + PKCE (steps 5–6)OAuth 2.1The main authorization flow; PKCE required
Token target binding (step 6)RFC 8707Nailing the token to the target MCP server

Feedback welcome ​

MCP server authorization is a roadmap capability. If you are choosing an authorization approach for an MCP server, tell us about your setup: where the MCP server runs, whether it faces internal employees or external users, and what scope granularity you need. Real scenarios decide the schedule and the shape of this work.

Next steps ​