Understanding MCP Auth: OAuth 2.1 Integration and Bearer Authentication for Function Compute

Background

The MCP protocol originally had no authentication support (2024‑11‑05). Starting with the 2025‑03‑26 release, MCP adopted OAuth 2.1‑based mechanisms. The latest draft treats the MCP server purely as a resource server and delegates authorization to an external OAuth provider.

OAuth 2.1 Overview

OAuth 2.1 defines four roles: Resource Owner (RO), Resource Server (RS), Client, and Authorization Server (AS). A typical flow is:

Client requests authorization from the resource owner (directly or via AS).

Resource owner grants an authorization grant.

Client exchanges the grant for an access token at the AS.

Client presents the access token to the RS to obtain protected resources.

Authorization Server Metadata (RFC 8414)

The AS exposes a well‑known endpoint /.well-known/oauth-authorization-server that returns a JSON document describing its configuration. Example response:

{
  "issuer": "https://auth.example.com",
  "authorization_endpoint": "https://auth.example.com/oauth/authorize",
  "token_endpoint": "https://auth.example.com/oauth/token",
  "response_types_supported": ["code", "token"],
  "grant_types_supported": ["authorization_code", "client_credentials"]
}

Dynamic Client Registration (RFC 7591)

Clients can register dynamically with the AS to obtain a client_id and client_secret without manual configuration. The registration response contains these credentials for subsequent token requests.

Protected Resource Metadata (RFC 9728)

If a client accesses a protected resource without a token, the RS returns a WWW-Authenticate header that includes a URL to a metadata document. The client can fetch this document to discover the associated AS information.

MCP Authorization Flow (2025‑03‑26 version)

The flow implemented in the 2025‑03‑26 version is:

MCP client calls the MCP server without a token and receives 401 Unauthorized.

Client fetches the AS discovery document from /.well-known/oauth-authorization-server on the server.

Client registers via the Dynamic Client Registration endpoint and receives client_id and client_secret.

Client initiates PKCE, builds the authorization request, and redirects the user to the AS.

After user consent, the AS redirects back with an authorization code.

Client exchanges the code (including the PKCE verifier) for an access token.

Client uses the access token to call the MCP server’s protected resources.

Latest Draft Changes

The newest draft treats the MCP server solely as a resource server. Authorization is delegated to an external OAuth provider, and the server must implement the Protected Resource Metadata protocol (RFC 9728) so that clients can discover the AS automatically.

The MCP server no longer embeds authorization logic.

Clients retrieve AS metadata via the PRM endpoint.

PKCE and standard OAuth flows remain unchanged.

Deploying an MCP Server with Bearer Authentication on Function Compute

Because the Function Compute gateway does not yet support full OAuth, a Bearer token mechanism is provided as a practical alternative.

Log in to the Alibaba Cloud console and open the Function Compute 3.0 console.

Create a new web function, select the MCP-Python-Python3.10 runtime, and finish creation.

In the function’s trigger configuration, change the authentication mode to Bearer and save.

The generated tokenData value must be placed in the Authorization: Bearer <tokenData> header when the MCP client accesses the function.

Verify the deployment with the MCP Inspector tool.

Supergateway Example for Tools Without Bearer Support

When a client tool cannot set a custom Authorization header, the supergateway utility can proxy the remote MCP server and inject the token:

{
  "mcpServers": {
    "cursorExampleNpx": {
      "command": "npx",
      "args": [
        "-y",
        "supergateway",
        "--sse",
        "https://your-function-url/sse",
        "--oauth2Bearer",
        "your-bearer-token"
      ]
    }
  }
}

After configuring the JSON, the tool can connect to the MCP server over HTTPS with the required authentication.

References

https://modelcontextprotocol.io/specification/2025-03-26/basic/lifecycle

https://github.com/supercorp-ai/supergateway

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12

https://datatracker.ietf.org/doc/html/rfc8414

https://datatracker.ietf.org/doc/html/rfc7591

https://datatracker.ietf.org/doc/html/rfc9728