Building a self-hostable MCP auth proxy that does silent refresh for any client, would you use it?

[Darshan Panchal]

I'm exploring a self-hostable MCP authentication proxy that sits between an MCP client and MCP server and handles OAuth token management transparently.

The main problem I'm trying to solve is token expiry and re-authentication. For example, if an MCP client receives a short-lived access token, the proxy would securely handle refresh/re-authentication in the background so the client doesn't repeatedly require the user to authenticate.

The goal would be:

• Self-hosted

• Client-agnostic

• OAuth/OIDC support

• Automatic/silent token refresh

• Secure token storage

• Multiple MCP servers/providers

• Minimal changes required on the MCP client side

I'm particularly interested in the Atlassian MCP use case because I've seen discussions around short-lived tokens, OAuth configuration, and clients requiring repeated authentication.

Would something like this actually solve a problem for you?

If you've built or are building a custom MCP client, I'd especially like to know how you're currently handling token expiration and refresh.

[Sami Shaik]

Hello @Darshan Panchal , 

Good question, and since nobody has taken it yet, here is an answer from the enterprise admin side of the fence, because that is where your adoption decision will actually be made.

Is the pain real? Yes, but only in one of the two use cases. For the Atlassian Rovo MCP Server specifically:

1. Headless and automation scenarios: Atlassian has already shipped the answer, and a proxy adds little there. If the org admin enables it, MCP clients can authenticate via API token with no browser flow at all, either a personal API token (Basic auth) or a service account API key (Bearer). No consent screen, no refresh dance, consistent access for backend services, bots and agents. Reference: https://support.atlassian.com/atlassian-rovo-mcp-server/docs/configuring-authentication-via-api-token/
2. Interactive, multi-client human use: this is where your proxy would live. Each client doing its own OAuth 2.1 dance, plus re-authorization when permissions change, is genuine friction for power users running several MCP clients. So the problem exists, but the market is narrower than "any client": it is multi-client power users and multi-provider dev shops, not the automation crowd.

Two design constraints will decide whether an enterprise ever deploys it, and I would treat these as requirements, not nice-to-haves:

1. Identity integrity. The MCP server enforces permissions per authenticated identity, tokens are consented per cloudId (site), and Atlassian's guidance is explicit that tokens are never shared between users. Your proxy must therefore keep one token per user per site and never multiplex several people through one stored credential, or it silently breaks the server-side permission model and makes the audit log lie about who did what. Reference: https://support.atlassian.com/atlassian-rovo-mcp-server/docs/authentication-and-authorization/
2. Control-plane compatibility. Org admins govern MCP connections through domain allowlists for OAuth tools and IP allowlists plus token scopes for API-token tools, all from the Rovo MCP server settings in Atlassian Administration. A proxy inserts itself into exactly these controls: its domain and redirect need allowlisting, its egress IP must pass the org's IP allowlist, and above all it becomes a token vault, which security teams will classify as a top-tier asset. Self-hosting helps your pitch, but the security review is the adoption gate, not the engineering. Reference: https://support.atlassian.com/security-and-access-policies/docs/control-atlassian-rovo-mcp-server-settings/

Your direct question, how expiry is handled today in practice: the pattern I recommend and use in enterprise setups is to split by interaction type. Anything unattended runs as a dedicated service account with an API key, one account per agent, least-privilege permissions, so there is no refresh problem to solve. Humans use OAuth as shipped and accept the occasional re-consent, because a permission change forcing re-authorization is arguably a feature, not a bug: it is the moment the user re-confirms what the client may do.

If you do build it, four things that will matter: per-user, per-cloudId token isolation as above; refresh material in an OS keychain or KMS, never flat files; pass re-consent through to the user when the server signals permission changes rather than silently swallowing it; and target https://mcp.atlassian.com/v1/mcp, since the old /v1/sse endpoint stopped being supported after 30 June 2026. And publish a short threat model with the project, it is the first artifact any security reviewer will ask for.

You would also get sharper builder-side feedback on the Atlassian Developer Community, since this board leans admin and end-user.