Skip to content

Client Credentials In the token HandlerΒ #881

@SoldierSacha

Description

@SoldierSacha

Is your feature request related to a problem? Please describe.
The MCP Authorization Spec 2.1.1 OAuth Grant Types mentions that both Authorization Code and Client Credentials should be handled.

Describe the solution you'd like
In /server/auth/handlers/token.py, we only currently support "authorization-code". It would be fantastic if we could support "client-credentials" as well.

class AuthorizationCodeRequest(BaseModel):
# See https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.3
grant_type: Literal["authorization_code"]
code: str = Field(..., description="The authorization code")
redirect_uri: AnyHttpUrl | None = Field(
None, description="Must be the same as redirect URI provided in /authorize"
)
client_id: str
# we use the client_secret param, per https://datatracker.ietf.org/doc/html/rfc6749#section-2.3.1
client_secret: str | None = None
# See https://datatracker.ietf.org/doc/html/rfc7636#section-4.5
code_verifier: str = Field(..., description="PKCE code verifier")
class RefreshTokenRequest(BaseModel):
# See https://datatracker.ietf.org/doc/html/rfc6749#section-6
grant_type: Literal["refresh_token"]
refresh_token: str = Field(..., description="The refresh token")
scope: str | None = Field(None, description="Optional scope parameter")
client_id: str
# we use the client_secret param, per https://datatracker.ietf.org/doc/html/rfc6749#section-2.3.1
client_secret: str | None = None

Describe alternatives you've considered
I mean it's just more convenient, so I don't have to do the whole PKCE exchange thing if it's not necessary.

Additional context

Image

Link to MCP spec: https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization#2-1-1-oauth-grant-types

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1Significant bug affecting many users, highly requested featureauthIssues and PRs related to Authentication / OAuthfeature requestRequest for a new feature that's not currently supportedimproves spec complianceWhen a change improves ability of SDK users to comply with spec definitionpending SEP approvalWhen a PR is attached as an implementation detail to a SEP, we mark it as such for triage.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions