Skip to content

(spec) Primitive authorization #850

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from
Draft

(spec) Primitive authorization #850

wants to merge 7 commits into from

Conversation

localden
Copy link
Contributor

Working draft for a pull request that tackles primitive authorization, as discussed in a Google doc. This work is complementary to #475.

Warning

This is a draft, therefore this description may be incomplete or inaccurate until the PR goes into review.

@localden
Copy link
Contributor Author

One of the interesting discussion points from @wdawson and @nbarbettini is whether this belongs at protocol-level or SDK level. I stronly agree that the authorization metadata should NEVER be exposed to clients, because clients are ultimately not the ones making authorization decisions. That being said, I am exploring whether there is value in having a unified approach for "annotating" the tools with authorization policy metadata.

@ayshsandu
Copy link

IMO, this proposal can be analogous to SecuritySchemas in the OpenAPI definition.
As MCP Auth is based on OAuth, clients don't make authorization decisions but make authorization requests to the AS. To make the authorization request, clients need to know what the resource server demands.

When an MCP client invokes discovery operations (such as `tools/list`, `resources/list`,
`prompts/list`, or `roots/list`), the server **MUST**:

1. Extract authorization context from the request (e.g., `Authorization` header)
Copy link

@ayshsandu ayshsandu Jul 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This implies that the initial token that is presented for discovery needs to carry all the authorizations for the user/app interacting at the given time, breaking the rule of just-enough privileges. In an agentic setup, primitive access is dynamic based on the reasoning at the host. Better if the discovery is orthogonal to authorization evaluation at the primitive level.


### Policy Engine Flexibility

The authorization framework is designed to be policy engine-agnostic. Servers **MAY**

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with this goal but its not clear to me how this works. Is the authorization field in the JSON example above just an opaque blob that can contain any values?

},
"authorization": {
"allowed_roles": ["admin", "contributor", "manager"],
"allowed_scopes": ["files:write", "workspace:modify"],

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This only support an "OR" logic, so that brings the question of how to support "AND" ?🙂

For reference, OpenAPI support both (even if their syntax is not very explicit, in my opinion).
If we want to support both, we could either reuse a similar syntax and come up with a more explicit one.

For example we could reuse JSON Schema's anyOf/allOf.

- OR syntax:

"authorization": {
    "required_scope": {"anyOf": ["files:write", "workspace:modify"]},
}

- AND syntax:

"authorization": {
    "required_scope": {"allOf": ["files:write", "workspace:modify"]},
}

- single scope syntax:

"authorization": {
    "required_scope": "files:write",
}

This could be done similarly for roles.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants