Most MCP servers ship with static API keys and zero auth. Here's the identity crisis nobody's talking about, and what production-ready MCP auth actually looks like.
Last month, I tried to add OAuth to an MCP server I was building. The one that let Claude access our internal knowledge base.
Four hours in, I was reading RFC 9728, trying to figure out how Protected Resource Metadata discovery works, while debugging PKCE code challenges that kept failing silently. None of this had anything to do with the actual tool my MCP server exposed. Not one line of auth code made the knowledge base search smarter or the retrieval faster. I was burning a weekend on identity plumbing.
I shelved the auth work and shipped it with a static API key.
If that sounds familiar, you're not alone. And that shortcut is exactly why the MCP ecosystem has a massive security problem right now.
A research team at Astrix Security analyzed over 5,200 open-source MCP server implementations in 2025. What they found should make every developer building with MCP uncomfortable.
88% of those servers require credentials to function. But over half (53%) rely on static API keys or Personal Access Tokens. Long-lived. Rarely rotated. Sitting in environment variables.
Only 8.5% use OAuth.
Let that sink in. We have 7,900+ MCP servers in the ecosystem and counting. The protocol is supposed to be the "USB-C for AI." But the vast majority of these servers authenticate the way we did in 2015, before we knew better.
And it's not just theoretical risk. In June 2025, researchers found hundreds of MCP servers bound to 0.0.0.0 by default, exposed to any device on the same network without authentication. Attackers could connect directly and execute tools. They called it "NeighborJack." In January 2026, three CVEs dropped in Anthropic's own reference Git MCP server, the one developers copy as their starting template. Path traversal. File deletion. Remote code execution when chained with a filesystem server.
If Anthropic's reference implementation gets it wrong, what chance does your weekend project have?
Here's what most articles about MCP security get wrong: they blame the protocol.
The MCP authorization specification is actually solid. It mandates OAuth 2.1. Requires PKCE. Supports Dynamic Client Registration (DCR) and the newer Client ID Metadata Documents (CIMD). It separates the MCP server (resource server) from the authorization server, which aligns with how enterprises have run OAuth for years.
The problem is that implementing it correctly is really, really hard.
When you build an MCP server, the auth spec expects you to:
/.well-known/oauth-protected-resource