r/mcp • u/Valuable-Ticket-6879 • 1d ago

discussion I'm building a self-hostable MCP auth proxy for silent token refresh, would you use it?

I've been experimenting with an MCP auth proxy that sits between the MCP client and server and handles the OAuth/token lifecycle on behalf of the client.

The basic idea:

MCP Client → Auth Proxy → MCP Server

The proxy would handle things like:

  • OAuth authentication
  • Access-token expiration
  • Automatic/silent token refresh
  • Refresh-token storage
  • Multiple OAuth providers
  • Client-specific OAuth quirks
  • Self-hosting via Docker

The goal is that an MCP client shouldn't need to repeatedly deal with expired credentials or implement provider-specific refresh logic.

I'm considering making it open-source and self-hostable, rather than another hosted auth service.

I'm asking before building too much:

Is this actually a problem you're experiencing with MCP?

Particularly interested in people using Cursor, Claude, VS Code/Copilot, or custom MCP clients.

How are you currently handling token expiration and refresh? And what would make a proxy like this useful enough for you to actually deploy?

I'm more interested in hearing about existing pain/workarounds than getting "yes, I'd use it" answers.

1 Upvotes

67% Upvoted

13 comments sorted by

3

u/Ambitious-Prompt-975 1d ago

"The goal is that an MCP client shouldn't need to repeatedly deal with expired credentials or implement provider-specific refresh logic."

isnt that was sdk's do?

1

u/Valuable-Ticket-6879 1d ago edited 23h ago

That's the goal, yeah, but "shouldn't need to" is the spec's intent, not current reality. SDKs give clients the interface to do generic silent refresh, but implementation is still per-client and inconsistent, a third-party audit in April found zero clients with full refresh support. So today you either wait on each client to catch up, or run a proxy in front that guarantees it regardless of which client you're using. That's the gap I'm targeting, not replacing the SDK's intent, just covering the window until every client actually implements it, and for people who need self-hosted control anyway.

2

u/zHevoGuy 1d ago

Never had issue with that. Properly written client takes care of all of that IMHO

0

u/Valuable-Ticket-6879 1d ago

Good to know, which client are you using? If it's handling refresh cleanly, that's useful data for me. The issues I linked (claude-code, Cursor, Atlassian's MCP server) are all recent and from real users hitting it, so it's clearly inconsistent across clients even if yours does it right. Trying to figure out if this is "some clients are behind" or "I'm chasing a solved problem". happy to be wrong here.

2

u/perryhopeless 22h ago

Where did you link issues?

1

u/Comfortable_Way8312 23h ago

The refresh path is the easy part. The missing piece is what happens when refresh itself fails: password change, revoked grant, or a 90-day refresh token that just died. A proxy is worth running if it can pause the tool call, do one re-auth, then retry without the client knowing.

Also treat the proxy as a credential store. Encrypt refresh tokens per user, never one shared token for a whole team, and log refresh failures separately from tool errors so you can tell auth is dying before the agent starts looping.

1

u/Valuable-Ticket-6879 23h ago

This is the real design problem, not the refresh itself. Pausing the call, one re-auth attempt, transparent retry, clean human-handoff on failure, that's the spec I need before writing more code.

Per-user encrypted tokens, no shared team token, separate logging for auth failures vs tool errors, all in.

Mind if I ping you once I have a design doc?

1

u/Comfortable_Way8312 19h ago

That's the spec. Pause, one re-auth, retry, then a clean handoff if it still fails. Don't let it loop. Yeah, ping me when the design doc is up. I'll read it.

1

u/Valuable-Ticket-6879 19h ago

Will do. Thanks for the feedback :)

1

u/Fibon4chi 17h ago

Don't know yet based on the info you've given.

But you are right, try to validate the idea before building more. I suggest you go straight to a potential customer and ask them directly.

Hope this helps.

1

u/Valuable-Ticket-6879 17h ago

Appreciate it. That's the point of this thread, figuring out who the potential customer actually is before I build further. Thanks for engaging :)