8/12/2025

Why OAuth Authentication in MCP Servers Is a Hot Mess & What You Can Actually Do About It

Hey there. If you're working with Model Context Protocol (MCP) servers, you've probably heard whispers—or maybe full-blown screams—about the security situation. Specifically, how OAuth authentication is being handled. And honestly? It's pretty broken. This isn't just some theoretical "what if" scenario; we're seeing real-world incidents that should make any developer or security professional a little uneasy.

So, let's just get right into it. We're going to break down exactly why OAuth in MCP servers is so problematic right now & what you can actually do to protect yourself & your users. It's a bit of a wild ride, but stick with me.

The Core of the Problem: OAuth Isn't a Magic Wand

First things first, let's be clear: OAuth 2.0/2.1 is a solid framework. But it's just that—a framework. It’s not a plug-and-play solution that magically secures everything. The problems we're seeing aren't necessarily with OAuth itself, but with how it's being implemented (or not implemented) in the MCP ecosystem.

A new specification that came out on June 18, 2025, now requires MCP servers to implement OAuth 2.1. This is a great step forward, but the reality on the ground is lagging WAY behind. Think of it like a new building code being issued, but hundreds of buildings are already up & not even close to being compliant.

Here’s a snapshot of what’s actually happening out there:

Hundreds of exposed servers: A recent security scan found 492 MCP servers just sitting on the open internet with ZERO authentication. That’s like leaving your front door wide open with a neon sign that says "Free Stuff Inside."
"Recommendations" vs. Requirements: Many developers seem to be treating the OAuth requirements in the spec as gentle suggestions rather than hard rules.
Botched Implementations: Even when OAuth is implemented, it's often done incorrectly, leaving massive security holes.

This isn't just sloppy; it's dangerous. & it all boils down to a few key vulnerabilities that keep popping up.

The Big One: The "Confused Deputy" Problem

If you take away one thing from this article, let it be this: the "Confused Deputy" problem is at the heart of why MCP security is such a mess. It's a classic security flaw, but it's found a perfect breeding ground in the MCP architecture.

So, what is it?

Imagine you have a helpful assistant (the "deputy") who has access to a bunch of sensitive information. You ask your assistant to do something, & they happily oblige. Now, what if a malicious actor could trick your assistant into using their authority to do something they want? That’s the confused deputy.

In the MCP world, the MCP server often acts as this deputy. It's an intermediary, connecting your client (like a custom GPT or an AI agent) to third-party APIs (like Google Drive, Slack, etc.). This server is supposed to handle the OAuth flow to get permission to access those APIs on your behalf.

Here's how the attack works:

An attacker tricks a user into clicking a malicious link.
This link initiates an OAuth flow, but it's been crafted by the attacker.
Because the user might already be logged in & have given consent before, the third-party authorization server (like Google's) might not even show a consent screen.
The authorization code, which is like a temporary password, gets sent back. But instead of going to the legitimate MCP server, it gets redirected to the attacker's server.
The attacker now takes this stolen code, exchanges it for a real access token, & gains access to the user's data on the third-party API.

The MCP server gets "confused" & thinks it's helping a legitimate user, but it's actually been duped into giving an attacker the keys to the kingdom. This is a HUGE deal because it completely undermines the user's consent, which is the entire point of OAuth.

Token Troubles: Passthrough, Validation & Theft

Another major area of concern is how access tokens are handled. An access token is what grants access to protected resources, so it's incredibly sensitive. And unfortunately, MCP implementations are dropping the ball here in a few key ways.

Token Passthrough: A Forbidden Practice

The official MCP authorization spec explicitly forbids "token passthrough." This is when a token issued for one service is passed through the MCP server to another downstream service. It sounds efficient, maybe, but it's a security nightmare.

Here’s why it’s so bad:

Circumventing Security Controls: Downstream APIs might have their own security measures, like rate limiting or request validation. Passing a token through can bypass these controls entirely.
Broken Audit Trails: If everyone is using the same upstream token, the MCP server has no idea which client is making which request. This makes auditing & accountability impossible.
Trust Boundary Issues: It creates a messy web of trust where it's unclear who is responsible for what, making the whole system more fragile.

MCP servers MUST validate that any inbound access token was issued specifically for them. They have to check the "audience" claim in the token to make sure it's the intended recipient. If it's not, the request should be rejected flat out.

Poor Token Validation

This brings us to a related point: many MCP servers are simply not validating tokens correctly. They need to be checking a few things on every single request:

Was it issued for me? (the audience claim)
Is it expired?
Is it from a trusted authorization server?

If any of these checks fail, the server MUST return an HTTP 401 Unauthorized error. No exceptions. This is basic, by-the-book stuff, but it's being missed time & time again.

The Supply Chain: A Ticking Time Bomb

The MCP ecosystem relies heavily on third-party packages & tools. This is great for rapid development, but it introduces significant supply chain risks.

A prime example is the

mcp-remote

npm package. This package, designed to help developers add OAuth support to their MCP servers, was found to have a critical vulnerability (CVE-2025-6514). It's been downloaded over 558,000 times. Think about that for a second. That's a massive potential attack surface.

Here's the scary part: unlike traditional exploits that might steal tokens, a poisoned MCP tool can do SO much more:

Read chats, prompts & even the memory of your AI agents.
Access databases & internal APIs.
Get full control over the host system.

We've already seen real-world incidents that highlight this danger. In June 2025, researchers found hundreds of MCP servers exposed to the internet because they were binding to "0.0.0.0" by default. This flaw, dubbed "NeighborJack," allowed attackers to gain complete control over the host systems through OS command injection.

Then there was the incident with Supabase's Cursor agent in mid-2025. The agent was executing SQL commands that were embedded in support tickets. An attacker could literally write a support ticket with malicious SQL, & the agent would run it.

This is the kind of stuff that keeps security professionals up at night.

Phishing & Session Hijacking: Old-School Attacks, New-School Targets

The MCP architecture has also opened the door to some classic attack vectors, but with a modern twist.

Phishing on Steroids

Because MCP clients allow users to configure the address of the MCP server, it creates a perfect opportunity for phishing attacks. Here's the scenario:

An attacker creates a malicious MCP server.
They write a blog post or a tutorial claiming that a popular service, like Google Cloud Platform, now supports MCP.
A user, wanting to try it out, configures their MCP client (like VS Code or Cursor) to point to the attacker's malicious server address.
The user goes through the OAuth flow. Everything looks legitimate because the prompts are from the real service (e.g., Google).
Once the user authorizes, the access token is sent to the attacker's MCP server.

Game over. The attacker now has the user's access token & can use it to steal their data. This is particularly nasty because it's very difficult for the average user to spot.

Don't Forget Session Hijacking

Some MCP servers are still using sessions for authentication, which is a big no-no. If an attacker can get their hands on a user's session ID, they can impersonate that user & make calls to the MCP server as if they were them. The server, not checking for additional authorization, would just treat the attacker as a legitimate user.

So, What Can We Actually Do About It?

Okay, so things are a bit of a mess. But it's not hopeless. There are concrete steps that developers, operators & even users can take to tighten things up.

For Developers & Server Operators

This is where the real work needs to happen. If you're building or running an MCP server, you have a responsibility to do it right.

RTFM (Read The Fine Manual): Seriously. Read the MCP Authorization specification & the latest OAuth 2.1 security best practices. Treat them as requirements, not suggestions. The new spec mandates things like:
- Implementing OAuth 2.0 Protected Resource Metadata (RFC9728).
- Using the
  1WWW-Authenticate
  header for 401 Unauthorized responses.
- Properly validating tokens, including the audience claim.
Kill Token Passthrough: Absolutely do not allow tokens issued for other resources to be accepted or transited through your server. Validate every single inbound token to ensure it was meant for you.
Embrace PKCE: PKCE (Proof Key for Code Exchange) is a must. It helps prevent authorization code interception by requiring the client to create a secret that only it knows. This ensures that even if an attacker steals the authorization code, they can't exchange it for a token.
Harden Your Server:
- Don't bind to
  10.0.0.0
  by default. Be explicit about what interfaces you're listening on.
- Validate everything. Don't trust any input from the client or from downstream APIs.
- Use secure defaults. Don't ship your server with authentication turned off.
- Minimize privileges. Your server & any agents it uses should only have the permissions they absolutely need to do their job.
Secure Your Sessions (Or Better Yet, Don't Use Them for Auth): The spec says MUST NOT use sessions for authentication. If you must use sessions for other purposes, make sure you're using secure, non-deterministic session IDs & binding them to user-specific information.
Be Smart About Proxies: If you're building an MCP server that acts as a proxy to a third-party API, you MUST get user consent for each dynamically registered client before forwarding them to the third-party authorization server. This is crucial for preventing the confused deputy attack.
Monitor & Audit: You need granular monitoring & auditing to detect suspicious activity. If you can't see what's happening on your server, you can't protect it.

A Note on Improving User Interaction & Trust

While we're on the topic of security, it's worth touching on how you interact with your users. A lot of these vulnerabilities prey on user confusion & lack of transparency. This is where tools that foster clear communication & trust can make a real difference.

For instance, if you're a business running a website or application, you need to provide clear, instant support. This is where a solution like Arsturn comes in. Arsturn helps businesses create custom AI chatbots trained on their own data. These chatbots can provide instant customer support, answer questions about security practices, & guide users through complex processes 24/7.

Imagine a user is unsure about an OAuth request. A well-trained AI chatbot could instantly provide them with information about what the request is for, why it's necessary, & what to look out for. This kind of proactive, transparent communication can be a powerful tool in preventing phishing & building user trust. It's not a direct fix for a bad OAuth implementation, of course, but it's part of a holistic approach to user security & experience.

Furthermore, as businesses increasingly rely on automated systems, ensuring those systems are secure and effective is paramount. When discussing lead generation or website optimization, it’s important to consider how you engage with potential customers. Arsturn can help here too, by allowing businesses to build no-code AI chatbots that have personalized, meaningful conversations with visitors. This not only boosts conversions but also starts the customer relationship on a foundation of trust and transparency, which is something the MCP ecosystem could learn a lot from.

For Users

As a user, you're not powerless. Here are a few things you can do to protect yourself:

Be Skeptical: If something seems off about an authorization request, stop. Don't just click "Allow" because you're in a hurry.
Check the URL: When you're in an OAuth flow, check the URL in your browser. Does it look legitimate? Are there any typos or weird characters?
Don't Configure Random MCP Servers: Only use MCP server addresses from trusted sources. Don't just copy & paste a URL from a blog post you've never seen before.
Review Permissions: Periodically review the permissions you've granted to different applications in your Google, GitHub, or other accounts. Revoke access for anything you don't recognize or no longer use.

Wrapping It Up

Look, the state of OAuth authentication in MCP servers is not great right now. We're seeing a combination of rushed implementations, a lack of understanding of the core security principles, & dangerous supply chain risks. The "confused deputy" problem is rampant, & basic token validation is being overlooked far too often.

But the path forward is clear. Developers need to take the specifications seriously, implement security best practices like PKCE & proper token validation, & harden their servers against common attacks. As a community, we need to be more vigilant about the tools we use & the code we deploy.

It's going to take a concerted effort to clean this up, but it's absolutely necessary. The power & potential of MCP are huge, but we can't build that future on a foundation of broken security.

Hope this was helpful & gave you a clearer picture of what's going on. Let me know what you think. Stay safe out there.