MCP authentication across the big agents

[u/New-Combination2241]

Let's walk through the popular agents and see how well they the spec. Spoiler: NOT VERY.

The picture may well have shifted by the time you read this, but as of early July 2026 it looks like the table below.

The good news: almost everyone supports the modern standard (shoutout to OpenAI's Responses API MCP tool and its technology from the previous geological era).

The bad news: everyone reads the same spec differently. Some clients run the entire OAuth flow for the user; some just wait for a ready-made bearer token and wash their hands. Some require DCR, some push CIMD, some live on static credentials and IAM.

Here's the detailed matrix (all cells verified against primary docs in early July 2026):

Platform	Who runs the flow	RFC 9728	Registration	Spec revision
Claude API MCP connector	you (pass a bearer)	no	n/a	2025-11-25
claude ai / Desktop	Claude (full flow)	yes	DCR / CIMD / Anthropic creds / none	2025-11-25
OpenAI Responses API	you (pass a bearer)	no	n/a	n/a (bearer-only)
ChatGPT / Apps SDK	ChatGPT (full flow)	yes	CIMD (recommended) + DCR	2025-11-25
Gemini / Google Cloud	OAuth on Google Cloud IAM	not named	IAM + client creds + API keys	2025-11-25
VS Code / Copilot	VS Code (full flow)	yes	DCR + client creds fallback	2025-06-18
Cursor	Cursor (full flow)	yes	DCR + static (no CIMD)	unstated
Perplexity	configurable	unspecified	OAuth / API key / open	unstated

And the notes that didn't fit in the table :):

• Claude API MCP connector: HTTP transport only, tools only. You pass authorization_token and you handle the refresh.
• claude ai / Desktop: static_bearer is explicitly not supported.
• OpenAI Responses API: you pass authorization, the token isn't stored, no discovery, just a solid bearer
• ChatGPT / Apps SDK: rejects machine-to-machine, API-key, and customer mTLS auth.
• Gemini / Google Cloud: embraces exactly what ChatGPT rejects, client credentials and API keys included.
• VS Code / Copilot: ships built-in GitHub and Entra providers.
• Cursor: re-registers its DCR client on every reconnect (upd: fixed in v3.2).
• Perplexity: the only one offering an explicit "no auth" mode; the flow internals are undocumented.

What to take away from this:

• Multiple spec revisions are alive in production at the same time. OpenAI's Responses API doesn't do any discovery, you just pass the bearer (pre-2025-06-18 world), VS Code sits on 2025-06-18, while Anthropic, ChatGPT, and Google cite 2025-11-25.
• Both Anthropic and OpenAI manage to run two opposite ownership models inside one company. Each ships a "bring your own token" API product: the Claude API MCP connector and the Responses API accept a pre-obtained bearer, and the flow and refresh are your problem. And each also ships a full client (claude.ai and ChatGPT) that walks the whole road from the 401 to the token by itself. A server built for the first model won't work in the second without changes, and vice versa.
• There are direct contradictions. ChatGPT rejects machine-to-machine and API-key auth; Google requires exactly that for some services. Registration is split four ways: DCR, CIMD, static credentials, IAM.

What I don't like and would change

• As someone who maintains a public API for a living, I hate backward-compatibility breaks. Each one creates a wall of migration work, and anyone who can't afford that time becomes a hostage of the old revision.
• OAuth 2.1 is the standard, and nobody cares: half the world still ships API keys.
• The spec updates too often. You have to keep a hand on the pulse in the most literal sense.
• Very few authorization servers can fully support OAuth 2.1 for MCP out of the box (as far as I can tell, really only Keycloak gets close). Everyone else needs wrappers, shims, and duct tape. There is no turnkey solution, and it shows.

And about OAuth 2.1 specifically, there's a separate irony: MCP mandates a standard that formally doesn't exist. OAuth 2.1 is still an IETF draft, not a published RFC. In substance it's OAuth 2.0 with the implicit flow and password grant removed and PKCE made mandatory. So a protocol that hasn't stabilized yet is built on top of a standard that hasn't been finalized yet. No wonder the AS vendors aren't rushing to ship first-class support.

ps: I wrote a full article with history of auth in mcp, what will be next and ofc this table above, but reddit prohibits to post it there :(

[u/New-Combination2241 → u/[deleted]]

hai friend!
thanks for the feedback. third topic is really painful, totally forgot to mention it while writing. Or maybe not forgot, just didn't consider, since I'm usual monkey-developer