Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

OAuth token expiry equality boundary causes intermittent downstream test failures

Open Beginner friendly
  • Is something wrong?
#3,729 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

  • #3730 by @pei711 — closed without merging

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
74/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
authentication, backend

Research direction

Start by reading OAuthContext.is_token_valid() and update_token_expiry() in mcp/client/auth/oauth2.py, then check the token expiry tests. Reproduce the equality boundary with the provided fixed-clock example. Done when a token is invalid at its expiry timestamp and the tests cover both equality and a time just after expiry.

Written by the indexing model from the issue text.

Description

bug v1 v2
Initial Checks
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())  # False
Python & 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.
Dominant language
Python
Stars
24.6k
Forks
4.2k
Avg merge
10h 37m
Merged PRs (30d)
38

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from modelcontextprotocol/python-sdk

All issues in modelcontextprotocol/python-sdk

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.