-
Notifications
You must be signed in to change notification settings - Fork 3k
Open
Labels
P1Significant bug affecting many users, highly requested featureSignificant bug affecting many users, highly requested featureauthIssues and PRs related to Authentication / OAuthIssues and PRs related to Authentication / OAuthenhancementRequest for a new feature that's not currently supportedRequest for a new feature that's not currently supportedimproves spec complianceWhen a change improves ability of SDK users to comply with spec definitionWhen 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.When a PR is attached as an implementation detail to a SEP, we mark it as such for triage.
Description
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.
python-sdk/src/mcp/server/auth/handlers/token.py
Lines 26 to 47 in 5441767
| 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
heeki, dwreeves, jessesanford and YikaiHu
Metadata
Metadata
Assignees
Labels
P1Significant bug affecting many users, highly requested featureSignificant bug affecting many users, highly requested featureauthIssues and PRs related to Authentication / OAuthIssues and PRs related to Authentication / OAuthenhancementRequest for a new feature that's not currently supportedRequest for a new feature that's not currently supportedimproves spec complianceWhen a change improves ability of SDK users to comply with spec definitionWhen 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.When a PR is attached as an implementation detail to a SEP, we mark it as such for triage.