3 ms·

I don’t think this is a great article. MCP is inherently designed so integrating something like oAUTH is going to be very difficult. What callback url are you g

I don’t think this is a great article. MCP is inherently designed so integrating something like oAUTH is going to be very difficult. What callback url are you going to use? How are you going to pass the token in so it isn’t stored by the LLM provider? Etc.

boleary-gl 1y ago
You’re not wrong but also this does raise a central question that I think is super un-considered in this whole MCP thing: how are we handling identity in those contexts. If anything we should be more concerned so it that because of the power that it can hand over to agents.
- adamm255 1y ago
  Totally. Still getting my head around this write up but it goes into a lot of detail. https://aaronparecki.com/2025/04/03/15/oauth-for-model-context-protocol https://aaronparecki.com/2025/04/03/15/oauth-for-model-conte...
  - slowmovintarget 1y ago
    Following those guidelines, how do you not end up with a perpetual 401 response from the REST API? 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 1y ago
  I think this is the more important question too. I don't think it is right in many cases to use the identity of the user and provide access to these agents. If it a simple one-time task, that might work if you can give restricted temporary access to the agent. 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 1y ago
I feel the authorisation layer really needs to sit with the MCP server. Ultimately the LLM provider’s servers can’t be prevented from using a token however they want.
mdaniel 1y ago
> What callback url are you going to use? 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 https://datatracker.ietf.org/doc/html/rfc8252#section-7.1
po26511 1y ago
Are people generally concerned with security for stdio transport? Personally I can't see a use case for it since it, but wonder if I'm missing anything. 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.

boleary-gl 1y ago

You’re not wrong but also this does raise a central question that I think is super un-considered in this whole MCP thing: how are we handling identity in those contexts. If anything we should be more concerned so it that because of the power that it can hand over to agents.

adamm255 1y ago
Totally. Still getting my head around this write up but it goes into a lot of detail. https://aaronparecki.com/2025/04/03/15/oauth-for-model-context-protocol https://aaronparecki.com/2025/04/03/15/oauth-for-model-conte...
- slowmovintarget 1y ago
  Following those guidelines, how do you not end up with a perpetual 401 response from the REST API? 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 1y ago
I think this is the more important question too. I don't think it is right in many cases to use the identity of the user and provide access to these agents. If it a simple one-time task, that might work if you can give restricted temporary access to the agent. 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 1y ago

I feel the authorisation layer really needs to sit with the MCP server. Ultimately the LLM provider’s servers can’t be prevented from using a token however they want.

mdaniel 1y ago

> What callback url are you going to use? 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 https://datatracker.ietf.org/doc/html/rfc8252#section-7.1

po26511 1y ago

Are people generally concerned with security for stdio transport? Personally I can't see a use case for it since it, but wonder if I'm missing anything. 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.