"Authentication is tricky and so it was very fair that the designers chose not to include it in the first version of the protocol."
No, it's not fair at all. You can't add security afterwards like spreading icing on baked cake. If you forgot to add sugar to the cake batter, there's not enough buttercream in the world to fix it.
MCP can use HTTP or STDIO as transports.
There is no need to implement a new form of authentication that's specific to the protocol because you already have a myriad of options available with HTTP.
Any form of auth used to secure a web service can be used with MCP. It's no different than adding authN to a REST API.
Please just read the spec. It just builds on top of JSON-RPC, there's nothing special or inherently new about this protocol.
https://modelcontextprotocol.io/specification/2025-03-26
There are way too many commentators like yourself that have no idea what they are talking about because they couldn't be bothered to RTFM.
Exactly, lots of people without any idea on what's going on. I implemented an authenticated MCP that uses the context bearer token and passes it on to the backend. Fully authenticated and authorized.
I haven't read a good justification from them on this but it did seem reasonable to me that if the protocol allows auth to be added on top then it's less critical to be in the spec v1 itself.
It's not no security vs security but not standardized vs standardized.
Agree though that's it's not ideal and there will definitely be non zero harm from that decision.
I made a MCP server to access remote storage using any kind of protocols (S3, SFTP, FTP, .... ), and authentication was not as much of a problem that most people would make you think. Is it technically pure and beautiful? No. Does it work? Yes and you can check by yourself by pointing the mcp inspector to "https://demo.filestash.app/sse" and play around
I’ll admit I’m a total dunce with respect to using MCP but given it uses TLS why not just use mutual TLS and validate the client certificate for authentication? You don’t need to use higher level protocols for authentication if your transport protocol supports it already.
I would think authZ is the trickier unhandled part of MCP as I don’t remember any primitives for authorization denial or granularity, but, again, HTTP provides a coarse authZ exchange protocol.
There are 2 transports, HTTP and STDIO.
You can use whatever authN/authZ you want for the HTTP transport. It's entirely up to the client and server implementers.
Presumably STDIO depends on the local AuthN/PAM that enabled the user space IO to begin with? I suspect what people are concerned about is the authorization of the LLM to the agent and its data rather than authN. AuthN in stdio would be the user that started the processes, or went through some AuthN chain allowing stdio to forward (I.e., ssh, sudo, etc). Am I missing something?
The bigger issue is that we need a good why to authenticate more dynamically. In the context of a desktop app (desktop claude, claude code) where you are running an application locally, for your own purposes it can run as your own user.
But when you are running things in any kind of multi-user/multi-tenant scenario, this is much harder and the protocol doesn't really address this (though also doesn't prevent us from layering something on top). As a dumb (but real) example, I don't want a web-enabled version of of an MCP plugin to have access to my company's google drive and expose that to all our chat users. That would bypass the RBAC we have. Also I don't want to bake that in at the level of the tool calls, as that can be injected. I need some side channel information on the session to have the client and server to manage that.
Ok fair enough - effectively there needs to be an authorization propagation channel that is systematic and bypasses the LLM and probabilistic layers through to each endpoint through the server. The issue isn’t the MCP server and client themselves but that there’s no clear and defined way to pass authZ through to the other side. AuthN should be handled at the interface and the AuthZ propagation is the crucial missing piece. Right?
Yep - that is my take. It isn't a weakness of MCP as such, but it a gap for which no good tooling exists afaik.
No they are concerne with SSE/HTTP as some made some MCP server over HTTP without auth in 2025. Then call it MCP issue.
Right - that’s my point. It’s janky to put AuthN into a high level protocol like MCP when low level protocols do a better job that’s more reliable and thoroughly vetted. You can do full on SAML etc and go hog wild without ever touching MCP while inheriting all the thorough analysis and implementation pressure testing down stack. Doing something unsafe because you don’t know what safe looks like isn’t application protocols fault.