MCP OAuth: Connecting Agents to Protected Servers

Static API keys in client config are the easy way to authenticate an MCP server and the easy way to leak a credential. The Model Context Protocol’s answer is OAuth: let the agent obtain a short-lived, scoped token through a proper authorization flow instead of carrying a long-lived secret around. It is the right direction. It is also where a single agent’s clean flow turns into a fleet’s token-management problem.

How MCP OAuth works

The MCP authorization spec builds on OAuth 2.1. A remote server advertises that it is protected, and the client runs the authorization code flow to obtain an access token, rather than reading a key from a file.

The sequence, in short:

1. The client calls the server and gets a 401 with metadata pointing to the authorization server.
2. The client registers itself, often through dynamic client registration, so no manual client ID is needed.
3. The user is sent through the authorization server to grant consent.
4. The client exchanges the resulting code for a scoped access token, and refreshes it as it expires.

The agent ends up holding a short-lived token scoped to specific permissions, not a permanent key to everything. For a single client against a single server, this is a clear improvement.

Where it gets messy

The flow is clean once. It does not stay clean at scale.

Every client redoes it. Claude Code, Cursor, and Codex each run their own OAuth dance and store the resulting tokens their own way. The same person authorises the same server several times over.

Tokens scatter. Access and refresh tokens land in per-client local storage across every machine. There is no single place to see what is authorised or to cut it off.

Refresh and revocation are nobody’s job. When a token expires mid-task, the agent fails. When someone leaves, their tokens persist wherever their clients cached them.

No central policy. A valid OAuth token authorises the agent against the server. It still says nothing about which tools or arguments are allowed. OAuth scopes are coarse and server-defined; they are not MCP authorization.

OAuth solves the static-key problem and hands you a token-lifecycle problem in its place.

Handling OAuth at the gateway

An MCP gateway runs the OAuth flow once, centrally, and keeps the tokens off every client. The upstream OAuth connection is established and refreshed at the boundary. Clients authenticate to the gateway with a grant token and never touch the upstream OAuth tokens at all:

{
  "mcpServers": {
    "github": {
      "url": "https://proxy.policylayer.com/mcp/<server-uuid>/",
      "headers": { "Authorization": "Bearer <grant-token>" }
    }
  }
}

Behind that endpoint, the gateway holds the GitHub OAuth tokens, refreshes them as they expire, and attaches them only to calls that policy allows. One authorization flow instead of one per client. One place to revoke. And because the call still passes through policy on the way out, an OAuth-authorised agent is governed by the same per-tool, per-argument rules as everything else, not just whatever broad scope the server granted.

Short-lived tokens, centrally managed, with real authorization on top. That is what MCP OAuth was reaching for.

Related reading

• MCP gateway: what it is and why agent fleets need one
• MCP authentication: securing how agents and servers connect
• MCP authorization: scoping what agents can do
• Safely connect Claude Code to upstream MCP servers

---

Control what your agents can do through MCP.

Get started now →. The product is live.

Browse the policy library →. Pre-classified tools across thousands of MCP servers.

Read the MCP security reference →. What the boundary looks like.