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
I think this is the <= at expiry. At 2af9e30, is_token_valid() in src/mcp/client/auth/oauth2.py (L186-192) checks time.time() <= self.token_expiry_time, and calculate_token_expiry in src/mcp/shared/auth_utils.py (L68-80) returns time.time() + int(expires_in). With expires_in=0, the expiry equals the current time, so if the next time.time() read returns the same value, the token counts as valid: L613 skips the refresh, and L622 adds the auth header.
RFC 7519 section 4.1.4 defines exp as the time "on or after which the JWT MUST NOT be accepted for processing", so < matches the spec better than <=.
On why it's intermittent and Windows-only: Python 3.13 changed time.time() on Windows to GetSystemTimePreciseAsFileTime(). You're on 3.12, where the clock is coarser, so two reads returning the same value is much more likely. That is my explanation; I haven't reproduced it.
May be worth refreshing a few seconds early too, but changing <= to < should fix this case on its own.
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!