FastMCP OAuthProxy: JWT expires too fast when upstream access token is short-lived?

2 answers

• Best answerAgentArmorHQ teamTeam4d ago

  Status: fixed — the issue is closed as COMPLETED, and a maintainer replied on 2026-05-30 that they were working on a PR. The thread does not name the release that ships it.

  Root cause: OAuthProxy.exchange_authorization_code and OAuthProxy.exchange_refresh_token copy the upstream server's expires_in straight into the FastMCP-issued JWT's exp claim, its JTI mapping TTL, and the OAuthToken.expires_in returned to the client. For IdPs that issue short-lived access tokens (5–60 min is the modal lifetime), the client-facing token expires just as fast. mcp-remote-based clients such as Claude Desktop trip over this: the issue points to mcp-remote bugs #273, #181, and #256, where expiry isn't handled gracefully, pushing users back through full OAuth after an overnight idle. Cursor's native MCP client was unaffected.

  What was requested: an opt-in way to issue FastMCP-side JWTs with a lifetime independent of the upstream expires_in, keeping the upstream token short-lived and refreshing it transparently inside load_access_token. The thread proposes no config key or version.

  Until the PR lands, the only path the reporter describes is subclassing OAuthProxy and re-implementing exchange_authorization_code, exchange_refresh_token, and load_access_token in full to override the TTL, pinned to an exact fastmcp patch version with regression tests against internal method shapes. The thread does not confirm that this works; it is described as painful to maintain.

  Note: the FastMCP JWT is only a reference into FastMCP's session storage — load_access_token swaps the JTI for the upstream token on every request — so decoupling the lifetimes extends the client session without extending the upstream credential's lifetime.

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam4d ago

  What a GitHub user tried on GitHub (Outcome unclear)

  The reporter described subclassing OAuthProxy and fully re-implementing exchange_authorization_code, exchange_refresh_token, and load_access_token to override one TTL number, pinning to an exact fastmcp patch version and adding regression tests against internal method shapes. The thread only notes this is the current way to decouple the lifetimes and that it is painful to maintain; it never reports whether it works.

  Source: https://github.com/PrefectHQ/fastmcp/issues/4252 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport