MCP Breaks OAuth’s Pre-Registration Model

▶ Watch (7:08)

MCP clients connect to arbitrary servers they have never seen. That breaks OAuth’s assumption that a client developer pre-registers at each server. OAuth solved password sharing with the hotel key model. MCP needs more. Three areas needed change: client identification without pre-registration, dynamic discovery of the OAuth server from a single URL, and solving click-through fatigue in enterprise SSO.

Dynamic Client Registration and Its Operational Problems

▶ Watch (9:31)

Early MCP drafts used dynamic client registration. The client posts its name, logo, and redirect URLs to the server and gets a client ID. This works at small scale. At scale, every desktop app instance registers itself. The OAuth server’s database grows unbounded. Attackers impersonate real apps with no authority checks. The latest MCP spec replaces this with client ID metadata documents. Clients publish metadata at a URL and use that URL as the client ID. This solves the unbounded growth and impersonation problems.

Dynamic Discovery: From a Single URL to the OAuth Server

▶ Watch (13:47)

OAuth traditionally hardcodes the server’s endpoints into the client. MCP wants a user to paste a single URL and have everything work. The MCP server now points to an OAuth server metadata file via the protected resource metadata RFC. This RFC was first published in 2016 and ignored for almost a decade. MCP revived it. The spec allows the server to advertise its authorization and token endpoints dynamically.

Click-Through Fatigue and the Enterprise SSO Gap

▶ Watch (16:22)

In an enterprise, apps sit behind SSO. When an MCP client connects to a calendar app, the user is redirected through the IDP and then through an OAuth prompt. With many MCP servers, the user clicks through dozens of approval screens. This trains users to approve everything. Worse, the enterprise admin sees the SSO login but not the OAuth tokens issued to the AI tool. This creates a visibility gap called shadow AI. A new draft, the identity assertion authorization grant (cross-app access), aims to let the AI tool request tokens directly from the IDP without separate OAuth prompts.

Q&A

How can an MCP client request scoped access to a specific app through the IDP? The draft allows the MCP client to tell the IDP it needs read access to a particular app, and that can be included in the cross-domain token, though admin configuration will determine available options. ▶ Watch (22:10)

Notable Quotes

But MCP is just making this happen at such a scale that hasn’t happened before Aaron Parecki · ▶ Watch (8:40)

You will find that the very first version of this was published in 2016, and then nobody really cared about it for almost 10 years. Aaron Parecki · ▶ Watch (15:33)

it’s this massive visibility gap, which essentially ends up leading to this shadow AI Aaron Parecki · ▶ Watch (18:52)

Key Takeaways

  • MCP forces OAuth to support dynamic client registration without pre-registration, solved by client ID metadata documents.
  • Protected resource metadata RFC, ignored since 2016, was revived by MCP’s need for one-URL discovery.
  • Enterprise SSO creates a visibility gap that leads to shadow AI, addressed by the cross-app access draft.

About the Speaker(s)

Aaron Parecki is Director of Identity Standards at Okta, and active in multiple standards development organizations including IETF, OpenID Foundation, W3C, and MCP. He is an editor of OAuth 2.1 along with several other OAuth specifications.