- The CloudSec Rocket
- Posts
- Sailing into new waters... authorization in MCP
Sailing into new waters... authorization in MCP
Model Context Protocol or Major Credential Problem?
Nelson R
April 25, 2025
In this piece...
Today we’ll continue exploring the new Model Context Protocol (MCP).
If you missed my earlier rambling on this, check it out here.
Today, I'll discuss three points:
Why managing auth within the MCP world will be a significant challenge
Why we should care as cloud security specialists
How can we address this challenge? (tldr; use OAuth 2.1)
What’s the risk here?
Why will auth in MCP be a challenge?
MCP is a powerful new innovation in the AI ecosystem.
It will unlock interoperability between vast numbers of services and AI agents and open up amazing use cases for AI applications.
But security risks will also exponentiate.
As with the rise of distributed computing, microservices, and SaaS, it will be critical to manage authentication and authorization securely.
Hordes of early adopters will be so caught up in the excitement of the new tech that they won’t pay attention to how auth is managed.
They'll use highly privileged, non-expiring credentials and leave them lying around.
No-code tools like n8n and text-to-app platforms like bolt.new will pour gasoline on the fire of these weak auth practices.
If you vibe code your auth without understanding it, in the words of the ski instructor from South Park, "you're gonna have a baaad tiiime." (I say that lovingly as a fan of vibe coding).
Why care as cloud security specialists?
Why does MCP authorization deserve to occupy our limited brain space?
In tech, there are a small number of cornerstone concepts.
A cornerstone concept is a fundamental idea on which many other systems are built.
The cryptography underlying TLS and PKI infrastructure is the backbone of modern secure internet communication.
REST is the key language for web systems to communicate.
Learning these cornerstone concepts is a high-leverage investment of time because they apply broadly.
Contrast that to a lower-leverage time investment like learning how a software library implements a new feature.
That's local knowledge that quickly becomes obsolete when a better library emerges.
We don't know if MCP will qualify as a cornerstone concept.
But it's taking off like a rocket. Signs point to rapid adoption:
The main MCP GitHub organisation now tops 22 k followers and its reference-server repo alone exceeds 40k stars.
The TypeScript mcp-framework package is being pulled ~62 k times per week on npm, up ~38 % month-over-month.
Big-tech is joining the party: OpenAI, Microsoft, Replit, Windsurf and PayPal have rolled out MCP support in the last month or two.
Grappling with authorization in distributed systems is exactly the sort of problem we deal with as cloud security folks.
Authorization in MCP is a similar problem space and will be required knowledge in our careers as it ascends to protocol dominance.
Or should I say “proto-cool” dominance? Because, you know, it’s cool. I’ll see myself out.
Solution: OAuth 2.1
We have decades of experience in cybersecurity dealing with auth challenges in a cloud-focused, distributed world. We don’t need to reinvent the wheel.
What familiar authorization protocol fits to avoid the above risks?
The OAuth 2.1 protocol to the rescue.
OAuth 2.1 is a foundational pillar of modern web and cloud authorization.
This protocol allows third-party systems to access user data without requiring the user to provide their credentials to the third party.
Instead, the user can grant granular access to specific data or allow the system to take actions on their behalf, without handing over the keys to the kingdom.
Now, I’m going to level with you.
I’ve tried to understand OAuth 2.1 several times. Each time, I’ve felt my eyes glaze over. Then I go back to burping and walking into things.
It’s a protocol steeped in jargon and dry technical details.
But it’s the de facto standard for how modern cloud systems manage authorization, so we should be across it.
Whether we can leverage OAuth 2.1 depends on whether you're talking about a locally run MCP server or a remote one.
Local MCP (stdio) vs remote MCP (SSE)
Currently, there are two main contexts to run an MCP server:
Running an MCP server locally on the same computer as the MCP client. This leverages the stdio transport, a byte stream that uses the built-in standard input and output streams.
Running an MCP server remotely using an HTTP-based transport like Server-Sent Events (SSE). This is currently uncommon, but it will increasingly be something we see.
The first scenario of a local MCP server doesn’t work with the OAuth 2.1 protocol, since it is an HTTP-centric protocol.
OAuth 2.1 relies on requests, responses, and headers to work. These constructs don't exist in the stdio transport context, which is just a bidirectional byte stream.
If you're running your MCP server locally, you need to keep using local config files, environment variables, or credential stores for your credentials.
The second scenario — dealing with a remote MCP server — is where things get interesting. Here, the OAuth 2.1 protocol will be critical.
I say “will be” not “is” because this stuff is bleeding edge. The experts are still working out the best way to implement all of this.
OAuth 2.1: How it works
This fantastic video by Nate Barbettini is a great online resource for understanding OAuth 2.1. I’ve watched it a few times and will again.
If you don't have an hour to spare now, let's cover the key concepts.
We’ll use YodaMail, an app that reads a user’s Outlook emails and summarizes them in a cool Yoda voice.
Assume Microsoft Entra ID is used as the identity provider (IdP) to grant access.
Let’s start with the terminology:
Resource owner: the user that owns the data the application wants to access (i.e. the user whose emails YodaMail wants to summarize)
Client: this is the third-party application (i.e. YodaMail) that wants to access the user's data or act on their behalf.
Authorization server: the server provided by the identity provider (IdP) that allows or denies access. It issues authorization codes and access tokens and controls the user login and consent flow (i.e. Microsoft Entra IdP).
Resource server: this is the server containing the user data or service the client wants to access, usually via a web API (i.e. the Microsoft Graph API for mailbox access).
Grant type or flow: this is the set of steps the client needs to perform for access. There are a few variations depending on the use case.
Redirect URI: the URL the user is redirected to after completing the login and permission consent process on the authorization server (i.e. yodamail.com/callback)
Scopes: the specific permissions the client wants access to (i.e. reading the user’s mailbox, not sending emails as the user)
Front channel: a less secure or partially trusted traffic channel (i.e. the user's browser)
Back channel: a more secure and trusted traffic channel (i.e., a backend web server)
The basic OAuth 2.1 “Authorization code flow” (or grant type) is used when an interactive user can sign in and click “OK” to allow access.
The authorization flow looks like:
The resource owner (user) accesses YodaMail from their browser.
The client (YodaMail) sends the user to the authorization server (Microsoft Entra IdP).
The authorization server logs the user in and asks them to consent to YodaMail’s specific permissions.
The authorization server redirects the user to a YodaMail-provided URL, sending an authorization code back.
YodaMail exchanges this authorization code for an access token with the authorization server.
YodaMail accesses the user’s emails using the access token (plus client id, and secret.
The access token expires and is scoped to allow the specific permissions consented to (e.g., reading user mailbox).
Note: if you're drifting off, feel free to skip this section. It's not critical to the big picture of this post, but read on if you're curious.
You might ask: why does the authorization server send back an authorization code first, and then swap this for the access token?
Can’t the authorization server send the access token back straight away to YodaMail?
The Implicit flow grant type does this. It was recommended for single-page and mobile apps running on the frontend without a secure backend server (i.e. “public clients”).
However, this is less secure and has been deprecated in favor of authorization code with Proof Key of Code Exchange (PKCE).
Why is it a bad idea to send the access code straight back to the redirect URI?
The answer lies in the distinction between front channel and back channel traffic.
Front channel traffic traverses a less secure environment, such as traffic returning to a user's browser.
The user's browser is a higher risk environment. The user might have malicious extensions installed, or people could be looking over the user's shoulder.
In contrast, back channel traffic runs over more secure environments. For example, the backend web server for YodaMail can be hardened and is less exposed to the security risks of an end user's browser.
The OAuth 2.1 protocol under the authorization code flow ensures only the YodaMail app can exchange the authorization code for the access token.
This happens via a client registration process with the Microsoft Entra ID identity provider, which associates a client ID and client secret with the YodaMail app.
The YodaMail app needs to send the client ID and client secret along with the access token when making resource requests.
This mechanism ensures only the YodaMail app can use that access token to access the user's data.
Anyone dodgy who gets the authorization code from the user's browser can't do anything with it.
OAuth 2.1 in MCP
The current specification is messy. Like any bleeding edge protocol, things are still being worked out.
I spent hours trying to understand the current state of OAuth 2.1 within the MCP ecosystem and nearly gave up.
Then I realized that people way smarter than me were still debating the right way to implement this. That made me feel less like a dumb-dumb.
The 20,000-foot view is: “offload the authorization flows to a separate authorization server (i.e. Microsoft Entra ID or other IdP), and treat the MCP server as a resource server that doesn’t need to worry about that stuff.”
The current MCP authorization spec blurs the line between resource server and authorization server, causing confusion about the MCP server’s involvement in managing authorization flows, tokens, and more.
As a result, the community has released a new draft spec that separates concerns. This spec liberates the MCP server from complex auth flows and token management.
See my diagram below that captures the gist.
Note: the diagram is missing key details like PKCE and dynamic client registration but hopefully captures the essence of the way this might work.
In summary (ft. cool Yoda voice)
In keeping with the YodaMail example, let's end on a Yoda-fied summary of this blog post.
MCP Yoda, courtesy of Flux 1.1 Pro image gen
“A new power in the AI galaxy, the Model Context Protocol (MCP), it is. Great connection between agents and services, it promises, yes.
But beware! Great danger in security, it also brings, particularly with authentication. Like younglings eager for treats, early users may be, careless with credentials, leaving keys scattered, they might.
Easy tools, this carelessness they will feed.
Why notice must you, protector of the cloud? Because foundational, this MCP could be. Problems of distributed auth, familiar to you they are, hmmm.
Fear not the challenge, for an answer exists. The security wheel, reinvent we need not. OAuth 2.1, the wise path it is.
Access it grants, yes, without giving away the master key. Strong, it is, for MCP servers far away (using HTTP).
For local servers, trickier its use becomes. A bit of a mess, the current MCP auth rules are, still debated by the masters.
But clarity emerges. To separate authorization servers, the wisdom points. Simpler, the MCP server's role will be. Focused, it must remain. Yes, hmmm.”
— AI Yoda, courtesy of Gemini 2.5 Pro (Experimental)