There are widely used schemes (OAuth+OIDC+... etc.) that the industry is already using. The last two paragraphs are fluff. Not sure who this article is is meant for, but it's sloppy.
I'll focus on the access token for a moment. The article shows concerns with 3rd parties gaining access to the token. If the MCP Server is under your control, then you have the same level of risk as a browser or other local software leaking the token. If the MCP Server is run by the vendor of the API you are accessing, the level of risk is the same as if a REST API provider leaked the token. MCP being the protocol doesn't change that risk profile in a meaningful manner. It's only when you are using MCP Servers hosted by 3rd parties that you are opening the attack surface for token exposure further than it already was without MCP involved.
What I have been watching in the MCP space *is* concerning though. There are so many poorly educated (on the relevant risks) people making poor decisions about where their trust boundaries should be drawn and/or where they actually are located. I lurk on the reddit MCP channel and it's shocking seeing the level of ignorance (I mean this in a 100% non-derogatory manner) around what MCP even *is*, much less on how you should assess the risks involved.
Conceptually I love MCP for what it's meant to provide, but right now it's basically a gold rush with a large percentage of poorly prepared people.
Personally, the security conversations around MCP that interest me the most is provenance of context and protection of sensitive context. There's currently no effective way to have untrusted MCP Servers accessed after sensitive MCP servers without an unacceptable level of risk around data leaks.
gsibble•9mo ago
boleary-gl•9mo ago
If anything we should be more concerned so it that because of the power that it can hand over to agents.
adamm255•9mo ago
slowmovintarget•9mo ago
I understand the idea of separating the OAuth audience between the MCP Server and the REST API it wraps. What I don't understand is how the MCP Server itself gets authorized against the REST API, unless there's a privileged client (that is the MCP Server has an API client by which it identifies itself, and not the end user).
How do you operate within the privileges of the end user in that case? It seems like it would still require the REST API to accept some additional signal of the end user's identity in order to make the authorization decisions. So while the MCP Server access token is "no good on the REST APIs" you have the additional problem of either "trust me, I'm an MCP Server" or the MCP Server has to exchange the "no good" token for an equivalent "good" token that also somehow carries the index to limitations of the user (identity in the case of fine-grained access control, and scopes in the case of coarse-grained).
adityavinodh•9mo ago
But for any other long-term task that may span hours or days while needing access to various data sources or APIs, we need a system where the agent has its own identity (which may be tied to the user). Just as humans are, agents might not function in the ideal manner at all times. So, we might need a system to monitor 'karma' of these agents. That ways API providers can confidently provide access to both humans and agents, and limit their risk to dangerous agents.
spacebanana7•9mo ago
Ultimately the LLM provider’s servers can’t be prevented from using a token however they want.
mdaniel•9mo ago
There is actually a dedicated redirect_uri URN for fixing that: "urn:ietf:wg:oauth:2.0:oob" or, if the service is modern enough, RFC 8252 offers custom scheme support https://datatracker.ietf.org/doc/html/rfc8252#section-7.1
po26511•9mo ago
For the others, they're based on http so I imagine any existing authentication mechanism should be co-hostable, e.g. the callback url would be served next to the sse / messages endpoint.
Then it's just transporting credentials to the MCP handlers - I am expecting the `params._meta` field to become the bag that acts like HTTP headers.
Though anyways agree with the article being mediocre as it seems an unhelpful critique of oauth itself with no real relation to MCP other than to invoke clicks.