Except you’ve been dwelling underneath a metaphorical rock, you’ve in all probability heard about Mannequin Context Protocol (MCP), a brand new protocol from Anthropic that makes an attempt to offer a normal approach to offer instruments and context to Massive Language Fashions (LLMs).
On this submit, we’re principally going to disregard the precise options of MCP and deal with a key group query: How will we securely authorize entry to an MCP server? Till lately, there was no apparent resolution, however with among the newest modifications to the authorization part of the specification, we now have a brand new basis. And in case it isn’t apparent from the title, we’re going to be speaking about OAuth.
It’s not simply one OAuth specification both, however a handful, every layering on high of the final and fixing a unique drawback.
Spec #0: No Authorization
Within the very starting, model 2024-11-05 of the MCP specification didn’t cowl authorization as a priority, and so in hindsight, it was no shock to search out that just about all MCP servers from again then have been anticipated to be run on localhost. You’d configure your most well-liked shopper, like Claude, to start out the server, and all communication occurred over the STDIO transport.
This was okay whereas we have been all collectively nonetheless figuring issues out, nevertheless it has some vital issues.
First, you sometimes needed to be a developer, or at the least have improvement instruments put in, in an effort to run these MCP servers. This made MCP troublesome to undertake for non-technical customers—an space the place mannequin suppliers had in any other case excelled.
Typically, these native MCP servers have been supposed to work together with distant providers and due to this fact wanted to authenticate themselves. The standard resolution was to get an API credential for mentioned distant service and make it accessible to the MCP server by way of a file or atmosphere variable, typically in plaintext. I’m certain safety people love this.
Spec #1: Good ol’ OAuth 2.0
It seems that authorizing entry to a distant service on behalf of a consumer is an issue we’ve had on the internet earlier than, which leads us into our first spec: The traditional OAuth 2.0 Authorization Framework from RFC 6749.
!!Technically, MCP expects you to implement OAuth 2.1, however we aren’t going to get into the variations right here.!!
If we begin by assuming most MCP servers sooner or later might be operating remotely (i.e. not in your laptop computer like within the early days), then the items begin to match. Taking the usual “roles” that OAuth outlines:
- Useful resource proprietor: That is you. Somebody who makes use of a service, like say GitHub, and needs to let an LLM entry your GitHub assets over MCP.
- Useful resource server: That is GitHub’s MCP server, which requires credentials to be accessed (by your LLM).
- Consumer: That is your LLM, like Claude or Cursor, which might be given credentials to entry the MCP server.
- Authorization server: That is typically the service once more, corresponding to GitHub, and we’ll discover out quickly how we could be much more versatile right here with, you guessed it, extra specs.
With all the “actors“ taking part in their correct ”roles“, issues in principle change into easier. Connecting your LLM to an MCP server must be so simple as logging in along with your account, like signing into Medium along with your Google account.
However how do you inform your LLM about an MCP server? You can begin by giving it the URL of its Server-Despatched Occasions (SSE) endpoint, however there are fairly just a few extra particulars on the subject of OAuth, like places of the authorize and token endpoints. As well as, historically, OAuth purchasers must register themselves forward of time, and N new LLM suppliers instances M new MCP servers, means numerous registrations that must be taking place.
Spec #2: Protected Useful resource Metadata
So that you’ve bought the MCP server’s URL, however you continue to must know how to work together with it securely:
- What token codecs does it settle for?
- Which scopes are supported?
- Which authorization servers does it belief?
Relatively than hardcoding all of this and counting on assumptions, the server can publish a machine-readable metadata doc at a widely known location (/.well-known/oauth-protected-resource). That is outlined in RFC 9728, and it’s mainly a discovery doc for protected assets. When a shopper first makes an attempt to attach with none credentials, the server ought to return a 401 Unauthorized response and a WWW-Authenticate header with the trail to this well-known URL.
This metadata tells the shopper all the things it must know: what the useful resource is named, which authorization servers can situation tokens for it, and confirm these tokens. The configuration that used to require digging by way of docs turns into self-serve and standardized.
Spec #3: Authorization Server Metadata
As soon as the shopper is aware of which authorization server to make use of — based mostly on the aforementioned metadata — the following query is work together with it. Enter RFC 8414, which defines how authorization servers can publish their capabilities by way of their very own well-known endpoint (/.well-known/oauth-authorization-server).
This metadata solutions questions like: The place ought to the shopper redirect the consumer to log in? How does it change a code for a token? What scopes, grant sorts, and shopper auth strategies are supported?
With this in place, you don’t must construct customized config for every auth supplier. Your LLM can merely observe the pointers and adapt to every new atmosphere mechanically — which, for one thing like MCP the place customers could be integrating with dozens of providers, is a very large deal.
!!Your authorization server and MCP server don’t must be the identical server! The great thing about this separation of considerations means you possibly can mix your MCP server with an off-the-shelf appropriate authorization server like AuthKit and get began even sooner.!!
Spec #4: Dynamic Consumer Registration
There’s one final piece: registration. Historically, OAuth purchasers must be registered forward of time — typically manually — with the authorization server. However that mannequin breaks down shortly in an ecosystem the place any LLM might speak to any MCP server at any time, with new purchasers and servers being revealed day-after-day.
That’s why RFC 7591 permits purchasers to register themselves dynamically. As a substitute of emailing an admin or submitting a ticket, the LLM simply makes a POST request to the registration_endpoint and says: “Hey, right here’s who I’m, right here’s contact me, and listed below are the flows I need to use.”
The server can reply with a shopper ID, possibly a secret, and optionally some guidelines or scopes. The purpose is: it’s now attainable to construct absolutely self-serve, zero-touch shopper registration. And that’s important if MCP goes to scale to arbitrary purchasers and providers with out admin bottlenecks.
Spec #5: Proof Key for Code Alternate (PKCE)
Okay, so we’ve bought dynamic registration, metadata discovery, and OAuth 2.0 all working collectively. Your LLM is sort of able to provoke the circulate. However there’s one final drawback: it’s a public shopper.
In OAuth land, meaning your LLM just isn’t trusted as a secure place to retailer secrets and techniques — like a client_secret. These are nice in the event you’re constructing a backend service, however your LLM runs domestically or in a user-facing app. In the event you ship a secret with it, it’s not a secret anymore.
That’s the place PKCE (pronounced “pixie”) is available in.
PKCE, quick for Proof Key for Code Alternate (RFC 7636), was initially designed for cellular apps however is now commonplace apply for any public shopper. As a substitute of counting on a shopper secret, the LLM generates a one-time-use random string (the code verifier) and transforms it right into a code problem utilizing a hashing algorithm. This problem is distributed in the course of the authorization request. Later, when redeeming the code for a token, the LLM proves it’s the identical shopper by presenting the unique code verifier.
Why does this matter? It prevents attackers from hijacking the authorization code in transit — even when they one way or the other intercept it, they received’t have the code verifier wanted to complete the circulate.
In an MCP context, PKCE permits you to run solely within the open — with no secrets and techniques needing to be exchanged as a part of the dynamic registration course of, and no secret to presumably leak afterward.
All collectively now
In order that’s MCP authorization in 5 OAuth specs — from the common-or-garden beginnings of localhost-only servers to a future the place any LLM can uncover, register with, and get approved to speak to any MCP server mechanically.
Every spec we’ve coated builds on the final:
- OAuth 2.0 offers us the core authorization circulate.
- Protected Useful resource Metadata lets purchasers learn to speak to a server.
- Authorization Server Metadata explains get tokens.
- Dynamic Consumer Registration removes the necessity for handbook setup.
- PKCE permits these registered purchasers to authenticate with no need to retailer a secret.
Individually, every spec solves a selected drawback. Collectively, they type a sort of lattice: a standardized, composable option to plug collectively instruments, fashions, and providers securely. That’s an enormous win not only for builders, however for customers — those who simply need to join their LLM to their favourite device with out coping with tokens, scopes, or arcane config recordsdata.
In apply
At WorkOS we’ve spent the lengthy hours packaging all of those specs right into a single API that purposes can combine with.
We then constructed mcp.store, a web based retailer the place you possibly can order some cool swag utilizing an MCP shopper. All of it’s powered by the WorkOS API.In the event you’re trying to construct an MCP server of your individual, take a look at our MCP Authorization information.
Lastly, in the event you’re simply an OAuth nerd like us, check out our Careers web page. We’d love to speak.
