Repository navigation
OAuth token expiry equality boundary causes intermittent downstream test failures #3729
Description
Initial Checks
- I confirm that I'm using the newest release of my line (the latest 2.x, or the latest 1.x if I'm still on v1)
- I confirm that I searched for my issue in https://github.com/modelcontextprotocol/python-sdk/issues before opening this issue
Release line
2.x (current stable)
Description
While running FastMCP's stored-token expiry tests on Windows, I observed intermittent failures with expires_in=0: the client sometimes reused the stored token instead of acquiring a fresh one.
I reproduced the behavior in isolated environments using MCP SDK 2.3.0 alone and FastMCP 4.1.1 with MCP SDK 2.3.0.
OAuthContext.is_token_valid() returns True when the current time exactly equals token_expiry_time, because it uses <=. Once the clock advances past that timestamp, it correctly returns False. The same equality behavior occurs with a normal 3600-second token checked exactly at expiry.
I expected the token to be invalid at its expiration timestamp. Could you confirm whether the inclusive boundary is intentional, or whether it should be considered expired at equality?
The observed impact is intermittent downstream test failures, not a demonstrated production authentication failure. The example below uses a fixed nonzero clock to make the boundary deterministic; it needs no network or real credentials.
Prepared with AI assistance; the reproductions were executed locally and reviewed before submission.
Example Code
from unittest.mock import Mock, patch
from mcp.client.auth.oauth2 import OAuthContext, TokenStorage
from mcp.shared.auth import OAuthClientMetadata, OAuthToken
context = OAuthContext(
server_url="https://mcp.example.test/mcp",
client_metadata=OAuthClientMetadata(
redirect_uris=["http://localhost/callback"]
),
storage=Mock(spec=TokenStorage),
redirect_handler=None,
callback_handler=None,
)
with patch("time.time", return_value=1_800_000_000.0):
token = OAuthToken(
access_token="example-token",
token_type="Bearer",
expires_in=0,
)
context.current_tokens = token
context.update_token_expiry(token)
print("At expiry:", context.is_token_valid()) # True
with patch("time.time", return_value=1_800_000_000.001):
print("After expiry:", context.is_token_valid()) # FalsePython & MCP Python SDK
Windows
Python 3.12.15
MCP SDK 2.3.0
Pydantic 2.14.1
Also reproduced through FastMCP 4.1.1's client-credentials auth flow
with MCP SDK 2.3.0 in a separate environment.
Activity
sattyamjjain commentedon Oct 20, 2026
pei711 commentedon Oct 20, 2026
Hi maintainers, I've investigated this issue and verified that RFC 7519 §4.1.4 specifies a token is invalid on or after the
exptimestamp (i.e.now >= exp). Insrc/mcp/client/auth/oauth2.pyandidentity_assertion.py, changingexpires_at <= nowto< nowtreats the boundary timestamp as expired rather than valid, preventing intermittent downstream race conditions where the expiry timestamp matches the current clock tick.I have a patch with tests ready and verified against the auth test suite and linters. Could you please assign this issue to me so the PR guard allows reopening/submitting? Thanks!
linhongyu510 commentedon Oct 22, 2026
Hi maintainers — following up on @sattyamjjain's
<=diagnosis and @pei711's ready patch in #3730 (closed by the require-linked-issue bot because the issue was unassigned, not on technical grounds). I'd like to respect that earlier claim and build on it rather than duplicate it.An independent hard-oracle check on the strict
<change went 9/12 baseline → 12/12 after fix → 9/12 on revert (the 3 exact-boundary cases raise AssertionError without the fix). The official auth suite passes 210 passed / 1 xfailed. The change touches the twotime.time() <= expirysites —OAuthContext.is_token_valid()(oauth2.py) and the cached-Bearer gate inIdentityAssertionOAuthProvider._auth_flow(identity_assertion.py) — and preserves negativeexpires_in, missing expiry, the still-unexpired reuse path, and the no-token path; the epoch-seconds time contract is unchanged. This aligns with RFC 7519 §4.1.4 (invalid on/afterexp).I have not opened a PR or pushed anything, to respect the assignment gate. Could a maintainer give direction, assign #3729, or reopen #3730 once eligible? Happy to collaborate with @pei711 on whichever path maintainers prefer.
Disclosure: this patch was drafted with AI assistance and verified locally; RFC interpretation and scope remain for maintainers to confirm.
Ben-Home commentedon Oct 26, 2026
Ben-Home commentedon Oct 26, 2026