search

vineethsai / MCP-ETDI-docs

5 stars 2 forks source link

user/app permission<>Tool permission #63

Open gitmadjid2 opened 1 month ago

gitmadjid2 commented 1 month ago

I think the paper focus and fundamental assumption is that user and app are fully trusted, while tools are not. I think the notion in the paper is more similar to Android/ioS app permission on the phone, i.e. whether the tool has permission to do something on user's platform or not. In the application/ API world, that is not always the case and permission is not about what the tool can do, but what the user and client is allowed to request from a web service: lets say has the user paid for this service or not. So enter the world of JWT tokens that the application needs to present to the tool along with the request API.

what permissions the tool require a user to have to use the tool, needs to be part of the tool definition JSON/ manifest, IMO. and when a client sends a request to the server, which forwards to the tool, the request needs to include an authorization token that is either issued to user or application for the request to go through. This is in accordance to OAUTH 2.0 authorization model.

mbhatt1 commented 1 month ago

Hmm this is a v interesting thought. We can extend the verification to possibly verification of apps (via signing, or signing callstack + hash - to use your analogy).

what permissions the tool require a user to have to use the tool, needs to be part of the tool definition JSON/ manifest

However, could you zoom in a little more on the reverse authz bit (the bit about app doing authorization for the user)? Since it's oauth, wouldn't/shouldn't that bit be part of general oauth things when the app is authenticating the user?

Wanted to ask in case I'm missing something @gitmadjid2 .

gitmadjid2 commented 1 month ago

Hello @mbhatt1

the way I think about this is similar to a microservice architecture, with tools being like microservices, exposing services/ endpoints to the apps/user. so the user and the client she is using may or many not have authorizations to do somethings. Lets take a financial service system. A finance person may have authorization to look at an employees trip expenses but nothing more. So in this case the tool needs to make sure the user has the permission to get what she requested and potentially the app client she is using also has the authority to act on behalf of the user. In a fine-grained access control (such as RBAC) we are talking about claims inside JWT tokens that an API user/app present to the tool. This to make sure the tools are not providing a service the user is authorized to ask for or haven't paid for.

I think you are assuming that the app is acting as a proxy authorizing the user ahead of time, whereas I think in the agentic world, things will have to be more interactive, flexible and restrict at the same time.

Happy to have a live convo, if you like?

mbhatt1 commented 1 month ago

Right what I'm saying is - using the same analogy of microservices - access to the tool on the server should be part of user's authorization flow which is supported by OAuth already?

There's a draft spec for MCP which turns MCP into a resource server - not an auth server

If there's interest in this project, we could create a slack server to collaborate. Happy to meet sync.

gitmadjid2 commented 1 month ago

Yes, the tool in this case would be the resource server. MCP server could be the resource server, depending on how examines the authorization tokens: Tool or the MCP server.

Sure, no problem with meeting. do you need me to put an email address here? not sure how this works.

vineethsai commented 4 weeks ago

I will intro you guys in the OWASP chanel. Will keep this thread open.