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.