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).
slowmovintarget|10 months 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).