Claude.ai OAuth flow and token refresh

[PL-Peter]

I've been running the mcp-memory-service for some days now as a Docker container with SQLite backend behind a named Cloudflare tunnel, which worked exceptionally well.
I run a second container for the HTTP interface to feed documents into the database.

When I configure the tunnel in Claude.ai or in the mobile app, I get prompted for the API key to authenticate and the MCP server gets connected, tools get exposed, access is working as expected.

Instructing AI some time later to lookup something usually ends with a "tools are not available" and the MCP configuration being shown as "not connected" until I hit the "Connect" button and re-authenticate with the API key.
I've manually configured the MCP_OAUTH_ISSUER (subdomain.tld.com), MCP_OAUTH_TOKEN_ENDPOINT (subdomain.tld.com/token) and MCP_OAUTH_AUTHORIZATION_ENDPOINT (subdomain.tld.com/authorization) envvars.

The Cloudflare tunnel is setup with ZeroTrust enabled and for the Anthropic subnets (and my local uplinks) to bypass authentication.

I guess I'm just missing something obvious but I can't figure it out for the life of me.
Any ideas?

[omni-front]

sounds like the token might be expiring and not refreshing automatically. check if your token refresh logic is set up correctly in the mcp-memory-service. if you’ve got the oauth endpoints right but it's still not working, maybe dig into the logs to see if there's any clue when it disconnects. not sure beyond that, might be worth checking with the team on their discord or forums.

[doobidoo]

Hi @PL-Peter! Great setup — running behind a Cloudflare tunnel with ZeroTrust is a solid approach.

The behavior you're seeing (works initially, disconnects after ~1 hour) is a known limitation of our current OAuth implementation:

Root Cause

Access tokens expire after 60 minutes (the default MCP_OAUTH_ACCESS_TOKEN_EXPIRE_MINUTES=60), and our OAuth server does not yet issue refresh tokens. When the token expires, Claude.ai has no way to silently renew the session — it can only show "not connected" until you re-authenticate manually.

Workarounds (for now)

Option 1: Increase token lifetime

Set in your .env / container environment:

MCP_OAUTH_ACCESS_TOKEN_EXPIRE_MINUTES=1440

This extends tokens to 24 hours (the maximum). Not a permanent fix, but dramatically reduces the re-auth friction.

Option 2: Use API key auth instead of OAuth

If your Cloudflare tunnel already handles access control (ZeroTrust with Anthropic subnets bypassing auth), you may not need the OAuth flow at all. You can authenticate with a simple API key:

MCP_API_KEY=your-secure-key

The API key doesn't expire, so the connection stays alive indefinitely. Combined with your ZeroTrust setup, this is arguably more practical for a single-user deployment.

Option 3: Bypass the built-in auth entirely

Since your Cloudflare tunnel + ZeroTrust already authenticates requests, you could disable the service-level auth and let Cloudflare handle everything. Though I'd still recommend at least the API key as defense-in-depth.

The real fix: refresh token support

We're aware this is a gap. The OAuth registration endpoint already advertises refresh_token as a supported grant type, but the token endpoint doesn't actually implement it yet. Proper refresh token support would let Claude.ai silently renew sessions without user interaction.

If this is something you'd like to see prioritized, feel free to open a feature request issue — or even a PR! The relevant code is in src/mcp_memory_service/web/oauth/authorization.py.

Hope this helps — let us know how it goes!

[omni-front]

ah good catch, you're right. thanks for clarifying the limitation on the refresh token.

[PL-Peter]

Thanks for the heads-up.
The web UI at https://claude.ai seems to need OAuth in place, so just rolling with an API key needs a workaround.
An option would be to just drop something like https://github.com/sigbit/mcp-auth-proxy in front of the app container.
For a natively running instance this wouldn't possibly make much sense, for the dockerized one it looks like a viable option.

I'll also look into the possibilities with Cloudflare (there's the MCP server publishing feature for example).
Letting well established IdPs handle the heavy lifting is probably the best option for single user setups.

Exposing the MCP enpoint completely unprotected to Cloudflare is maybe not what normal users want to do. It just takes a single wrong decision on the Cloudflare setup to expose the whole operation to the Internet then, which - depending on the information stored - might end in disaster.

Thanks for reaching back so quickly.

[omni-front]

Sounds like a solid plan, using the mcp-auth-proxy or Cloudflare options could definitely streamline the OAuth process. Let me know how it works out!

[doobidoo]

Security Tip: Cloudflare API Token IP Restrictions

Since this discussion touches on Cloudflare tunnel and ZeroTrust configuration — a general best practice worth mentioning:

When creating or managing Cloudflare API tokens (e.g., for D1, Vectorize, or tunnel management), you should always consider adding Client IP Address Filtering to your tokens. This limits which IP addresses can use the token, significantly reducing the risk of abuse if a token is accidentally leaked.

You can configure this in the Cloudflare dashboard under My Profile → API Tokens → Edit Token → Client IP Address Filtering.

A few things to keep in mind:

• Add your server's public IP (or CIDR range) to the allowlist
• If your server uses IPv6, make sure to include your IPv6 /64 network as well (Python prefers IPv6 by default — see our troubleshooting docs for details on the IPv6 gotcha)
• For dynamic IPs, you may need to update the filter periodically or use a broader CIDR range
• This is especially important for tokens with write permissions (D1, KV, R2)

This won't solve the OAuth token refresh issue discussed above, but it's a good layer of defense-in-depth for anyone running mcp-memory-service with Cloudflare backends. 🔒

[omni-front]

that tip! Implementing IP restrictions for API tokens is indeed a great security practice.

[PL-Peter]

Final solution (for now)

(Named) Cloudflare tunnel

• Name-based routing of services to the backend
• Subnet-based access control for MCP resources
• Authentication layer before hitting self-hosted resources
• Tunnel endpoint in a Docker container

MCP auth/aggregation

AuthMCP

• Handles routing to backend MCP servers after authentication with locally managed users
• Admin UI with access to access/auth logging and tool usage
• Mechanisms to limit access to specific MCP servers per user account
• Supports Bearer token authentication with backend MCP servers
  (there's quite a bit more on the feature list)

mcp-memory-service

• Running two instances with access to the same SQLite backend (single user + AI, concurrent access won't happen) in Docker
• One container handling MCP duties, the other handling the web UI for direct document ingestion
• Authentication via classic API key

Conclusion

The setup involved trial and error, but it wasn't brutal. Not for everyone, but manageable if you know Docker and networking.
The quality of life that session-independent memory adds to AI workflows is immense. File-based memory demands constant discipline. Semantic recall from a live database doesn't.
Storing data on my own hardware while making it remotely accessible across platforms turned out to be a feature I didn't know I needed. If you're running multiple AI workflows and want persistent context without third-party custody, this stack delivers.
Thanks for building this.

[doobidoo]

@PL-Peter "File-based memory demands constant discipline. Semantic recall from a live database doesn't." is exactly what I celebrate! And you name it: "privacy" and "context" is King.
Thanks for throwing this in.

[omni-front]

Nice, glad that sorted it out. Looks like a solid setup with the Cloudflare tunnel and MCP auth.

[doobidoo]

Quick follow-up for anyone landing here: refresh_token grant with rotation per SEP-2207 shipped in v10.41.0 (PR #766, merged 2026-04-28). The 1-hour expiry behaviour you saw should be gone — claude.ai connectors now refresh transparently against the upstream /oauth/token endpoint. If you upgrade and still see re-auth prompts, worth opening a fresh issue.

[omni-front]

Nice, glad that update addressed the issue. Thanks for sharing the solution!