-
Notifications
You must be signed in to change notification settings - Fork 173
Introduce require-oauth flag to comply with OAuth in MCP specification #170
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
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
e2c19d2 to
9540bd8
Compare
When this flag is enabled, authorization middleware will be turned on. When this flag is enabled, Derived which is generated based on the client token will not be used.
This commit adds authorization middleware. Additionally, this commit rejects the requests if the bearer token is absent in Authorization header of the request.
Per Model Context Protocol specification, MCP Servers must check the audience field of the token to ensure that they are generated specifically for them. This commits parses the JWT token and asserts that audience is correct and token is not expired.
This commit sends online token verification by sending request to TokenReview endpoint of API Server with the token and expected audience. If API Server returns the status as authenticated, that means this token can be used to generate a new ad hoc token for MCP Server. If API Server returns the status as not authenticated, that means this token is invalid and MCP Server returns 401 to force the client to initiate OAuth flow.
Member
Author
Member
Author
|
/hold |
Member
Author
|
@manusa this is ready for review, when you have a chance. Thanks. |
manusa
reviewed
Jul 11, 2025
manusa
approved these changes
Jul 14, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #161
Fixes #160
After the in-depth review of model context protocol specification and pondering about what would be the best approach in Kubernetes, I decided to propose the following path to comply with OAuth in this MCP Server.
This PR proposes the following;
--require-oauthand--authorization-urland--server-url(they are hidden for now)--require-oauthis set, authorization middleware for SSE and Streamable HTTP transport types will be enabled.This middleware basically;
Authorizationheader (if not, returns 401 as defined in protocol)TokenReviewrequest to API Server to validate the token online. Result ofTokenReviewis embedded into context of the HTTP Calls.IfMCP Server serves--require-oauthis set,.well-known/oauth-protected-resourceendpoint to serve the authorization url of the cluster. Authorization url can be specified via toml configuration or flag. If it is unspecified, API Server host name defined in the MCP Kubeconfig will be used.