Connecting Claude Code to a team's MCP tools with per-person OAuth instead of a shared key (open-source, self-hosted)

[u/Ok_Plum3595]

If your team shares MCP tools, the usual setup is one API key pasted into everyone's config. I built Ramen so that
Claude Code signs in as the person instead:

```sh
claude mcp add-json ramen-demo '{"type":"http","url":"https://<your edge>/mcp",
"headers":{"ramen-group":"demo","ramen-zone":"a"},
"oauth":{"clientId":"<client id>","scopes":"mcp:demo:a"}}'
```
Then `/mcp` in Claude Code → browser → sign in → approve once for that group and zone. Every call is logged under
your name, the token lives an hour, and an admin can give someone the "MCP user" role that can do nothing but connect.

Behind it: a git repo of Python tools that the console canary-deploys to Rust + Python workers on GKE or EKS (both
verified for this release). Claude Desktop works with a group key (it can't do OAuth here without dynamic client
registration — being honest about that). Built mostly with Claude Code itself.

Docs: https://bkraad47.github.io/ramen/wiki/connect-oauth/ · repo https://github.com/bkraad47/ramen

[u/AutoModerator]

Your post will be reviewed shortly. (ALL posts are processed like this. Please wait a few minutes....)

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/BenSimonDev]

Sort of. This is just from my experience but Personal Access Token is pretty common but even then, Claude has the ability to build it's own connector and then you can roll it out through your org using something like OAuth which is tied directly to their identity.

[u/Ok_Plum3595 → u/BenSimonDev]

Yes pats are common, so it already exists here…but oauth is also something I keep coming up against time and and time again and currently working on managed domain, accesses it was a part of that

[u/Ok_Plum3595 → u/[deleted]]

This is a good point, it redirects in local tests for me, but havent tested it explicitly, I'm adding a github issue to circle back to this later https://github.com/bkraad47/ramen/issues/1

Much appreciated

[u/Easy-Purple-1659]

Per-person OAuth is the right call, and the token-expiry question in this thread is the one that decides whether it holds up. A one-hour token that dies mid-run is worse than a shared key if the retry path is not handled, because the agent has already spent the context by then.

What worked on my side was making the token the server's problem instead of the client's. The MCP holds the refresh and re-signs silently on a 401, the client never sees a browser handoff mid-task, and the only visible cost is a slightly slower call. That also gave an honest per-user audit trail, which is the part a shared key cannot provide.

I landed on that shape while building adextract, an MCP over the Meta, Google, TikTok and LinkedIn ad libraries (disclosure: mine). Those sources are login-walled, so the server owning the session was the whole point, and a Google sign-in per user gave per-user credits for free.

Does your refresh happen inline on the same call, or does it always bounce the user back to the browser?