The current draft implementation of auth treats the MCP server as a OAuth authorization server. This means that every MCP server developer needs to implement the discovery, registration, authorization and token endpoints. It's much simpler if you treat the MCP server as an OAuth resource server and let it leverage an existing identity provider/authorization server.

Treating the MCP server as an OAuth resource server would allow the MCP server to be stateless when it comes to auth concerns. By leveraging existing authorization servers, the MCP server can support enterprise scenarios where the MCP client application retrieves the token using any supported OAuth flow by that Auth server. (i.e. client credentials, device code etc)

• This increases adoptability of MCP in enterprise scenarios where OAuth authorization servers are already deployed.
• Reduces the complexity when developing MCP servers.
  • MCP server doesn't need to keep track of bounded tokens/sessions.
  • Reduces the blast radius in case of an vulnerability.
• Increases the flexibility for MCP clients as they can leverage any supported OAuth flow to retrieve a token.
• Allows the MCP server to use the token exchange flows to act on-behalf-of the user.

An example scenario using token exchange flow

An organisation has a plethora of REST APIs that they have built over the years and would like to expose them via MCP servers. The API's are protected by JWT bearer auth and they have existing OAuth Authorization servers. The easiest path for adopting MCP would be to leverage their existing auth solution and treating the MCP server as just another middle tier service that needs to consume their existing APIs.

Edit: Updated the mermaid diagram to be explicit about how client Discovers the Identity Provider.

sequenceDiagram
    participant Client as OAuth Client/MCP Client
    participant AuthServer as OAuth Auth Server
    participant MCP_SERVER as MCP Server
    participant API_SERVER as API Server

    Client->>MCP_SERVER: 1. Request Metadata Discovery (or request a protected endpoint)
    MCP_SERVER-->>Client: 2. Respond with Identity Provider Info and scopes etc (or Status Code 401 with WWW-Authenticate header)
    Client->>AuthServer: 3. Perform RFC8414 Discovery (.well-known/oauth-authorization-server)
    AuthServer-->>Client: 4. Return Authorization and Token URIs, Supported Algorithms, Grant Types
    
    Client->>AuthServer: 5. Request Token with correct scopes
    AuthServer-->>Client: 6. Issue Token
    Client->>MCP_SERVER: 7. Call MCP Server with Token
    MCP_SERVER->>AuthServer: 8. Exchange Token for API Server
    AuthServer-->>MCP_SERVER: 9. Issue New Token
    MCP_SERVER->>API_SERVER: 10. Call API Server with Exchanged Token