-
Notifications
You must be signed in to change notification settings - Fork 748
Add header to MCP server to expand authentication capabilities #229
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
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please share more about the motivation for this change. As it stands, this isn't compatible with all transports, so it's extra important to have detailed justification and examples of how you'd use it.
This merge request would help me too. I would like to forward the authorization headers from the user to the actual tool use. So that the tool request can be done "in the name" of the original user. The backend is filtering out data based on the users permissions so i can not just use a service account for that. |
The addition of this feature is proposed by our team, the starting point is to strengthen the ability of mcp, and then the actual use of the process, we hope that he can be used as we use http network requests, you can isolate the user's request for business data and some of the system data, you can do more things, for example, we can add the header object to add sourceclient to determine the source of the user , you can add the header object auth_token to do the login credentials to pass , you can add any field to do the B-side of the user wants to do things , such as adding a parameter encryption field , you can do some of the anti-climbing mechanism and so on. |
…/dependabot/npm_and_yarn/npm_and_yarn-7631eb0223 Bump vite from 5.4.12 to 5.4.15 in the npm_and_yarn group across 1 directory
Hi There. This is a much needed feature. We are linking our internal backoffice systems via an MCP SSE server to our Chat Clients. The user is therefore able to search in different backend systems. However we need to be able to isolate the user via a header. If we have that header available in the Tool/Resource context we can do a Search/Fetch API call on the backend with that specific user context and therefore only returning data which is accessible to that user. |
Motivation and Context
This change introduces header-based authentication for MCP, improving security and access control. By requiring authentication headers in requests, we ensure that only authorized users can interact with MCP services.
How Has This Been Tested?
Breaking Changes
No breaking changes; existing authentication mechanisms remain functional, and this addition does not affect previous implementations.
Types of changes
Checklist
Additional Context
This implementation enhances security while keeping the request structure simple and efficient. No changes were made to the core authentication logic beyond requiring the new header.