MCP authorization

OAuth for Model Context Protocol servers and clients — scoped tokens, consent, discovery.

Model Context Protocol servers are resource servers, and MCP clients (agents) are OAuth clients. oauth.work issues real OAuth 2.1 access tokens for them — scoped, consented, and discoverable — so an agent connects to a tool the way the spec intends, not through a shared API key.

Discovery

An MCP server advertises its authorization server. Point it at the tenant’s issuer:

{
  "resource": "https://tools.acme.com/mcp",
  "authorization_servers": ["https://acme.oauth.work"]
}

Authorize the agent

The agent runs the authorization-code + PKCE flow and requests only the scopes the tool exposes. Consent is explicit — the user (or an admin policy) approves what the agent may do.

GET /authorize
  ?response_type=code
  &client_id=agent-research-bot
  &resource=https://tools.acme.com/mcp
  &scope=mcp:read mcp:tools.invoke
  &code_challenge=<S256>

Call the tool

The resulting access token is sender-constrained (DPoP) and scoped to exactly the tools granted. The MCP server validates it against the tenant JWKS and the aud/resource claim before running anything.

POST https://tools.acme.com/mcp
  Authorization: DPoP <access_token>
  DPoP: <proof-jwt>

A stolen MCP token is inert without the agent’s private key, and every invocation lands on the tenant audit trail. For multi-agent chains, see A2A delegation.