github
Non PAT auth method
Describe the feature or problem you’d like to solve
PATs are long lived credentials that are discouraged, and sometimes entirely restricted in many organizations. This limits the organizations from taking advantage of this MCP server.
Proposed solution
Please provide an alternative Auth method, e.g an OAuth with a device_code, in addition to the PAT, to enhance security and enable adoption within the aforementioned organizations.
Additional context
Example Github App auth: https://docs.github.com/en/apps/creating-github-apps/writing-code-for-a-github-app/building-a-cli-with-a-github-app
Hey folks! 👋 I'd love to take a stab at implementing the OAuth 2.0 device code flow as an alternative to PATs.
My plan:
- Integrate GitHub OAuth using the device_code grant
- Ensure it works cleanly with the current CLI setup
- Add documentation for setup and usage
Let me know if this is something you're open to having in a PR! 🙂
This issue is stale because it has been open for 60 days with no activity. Leave a comment to avoid closing this issue in 10 days.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Disappointing this is still lacking! Would love to have support for modern auth methods for MCP here.
@kentcdodds our hosted remote server does support OAuth. We have some info on how Hosts can support it here: https://github.com/github/github-mcp-server/blob/main/docs/host-integration.md
That doc is pretty confusing. Most MCP servers that support the MCP authorization spec just need a URL and the host application handles everything. I have authenticated MCP servers working in Claude, Cursor, VSCode, and others without having to do anything more than provide the URL for the remote MCP server. I assumed that URL would be https://api.githubcopilot.com/mcp/ based on the github repo, but every client I try it in fails to connect like the other servers I'm using.
@kentcdodds we're working on DCR (dynamic client registration) to make this much easier on the hosts. Thank you for chiming in here as it helps us prioritize!
Dynamic client registration would fix all our woes on the auth front for this MCP server, and bring things up to date with the rest of the MCP ecosystem. Looking forward to getting it shipped!
It's unclear to me if GitHub is expecting 3rd parties like Cursor to update something on their end for OAuth to work with GH MCP or if GitHub is actually working on DCR that will fix this. This is blocking us from using the MCP server as we don't allow employees to use PATs. The lack of this support is creating a scenario where developers are using less secure methods of authentication. This is especially dangerous with a new frontier like MCP servers. Can we get a clear update on this?
This issue is stale because it has been open for 30 days with no activity. Leave a comment to avoid closing this issue in 60 days.
@toby is there an issue for said Dynamic Registration that we can link here and follow for updates?
There is a blocking issue regarding DCR which involves automatic app creation. As a major Oauth provider we cannot make changes only for MCP where there are fundamental issues that impact customers and integrators. We are looking at the new spec's CIMD inclusion which solves a portion of the issues, but it's likely still months away (and not guaranteed to happen).
We do have documentation but if agents you are using support bring your own oauth app, it's actually really easy to set one up in the developer settings in GitHub (and for speed an Oauth app is lower friction than a GitHub app). You can share a client ID and client secret (as long as you don't mind other people potentially getting a token via your created app), all it does is allow them to log in as themselves.
I appreciate the friction this causes, and I'd love it to just work as much as you all 💟 , so I will continue to push internally for a solution and we will keep you updated, but it's not something we can address immediately.
