[pei711]

Fixes #3729

Summary

In OAuthContext.is_token_valid() and IdentityAssertionOAuthProvider._auth_flow, token validity against expiry was evaluated using <=:

time.time() <= self.token_expiry_time

Under RFC 7519 §4.1.4, expiration time (exp) defines the moment on or after which the token must not be accepted for processing. At exact equality (current_time == token_expiry_time), the token has expired.

Using <= caused:

• Tokens issued with expires_in=0 to evaluate as valid when inspected within the same clock tick (time.time() == token_expiry_time), skipping token refresh.
• Intermittent failures in downstream test suites (e.g. FastMCP stored-token expiry tests) on systems where time.time() resolution is coarse (such as Windows with Python 3.12).

Changes

1. In src/mcp/client/auth/oauth2.py:191, change time.time() <= self.token_expiry_time to time.time() < self.token_expiry_time.
2. In src/mcp/client/auth/extensions/identity_assertion.py:170, change time.time() <= self._expiry to time.time() < self._expiry.
3. In tests/client/test_auth.py, add test assertions covering exact expiry boundary equality and immediate invalidity for expires_in=0 tokens.

Testing

• Verified with pytest tests/client/test_auth.py (160 passed, 1 xfailed).
• Verified with ruff check and ruff format --check.
• Type-checked with pyright.

---

Disclaimer: This pull request was created with AI assistance and validated through local test execution.

[github-actions]

This PR has been closed automatically. This repo only keeps pull requests open when they come from a maintainer, or from a contributor a maintainer has assigned to the linked issue, and you aren't currently assigned to #3729.

If a maintainer assigns you to #3729, this PR reopens on its own and there's nothing more you need to do here. Assignment is a maintainer call based on capacity; comments that only ask to be assigned don't factor in. What does help is engaging on the issue itself by confirming the repro, explaining why it matters for your use case, or describing the approach you'd take.

You're welcome to keep pushing commits here (just avoid force-pushing, since GitHub can't reopen a rewritten branch), but that on its own won't get the PR reviewed or the issue assigned, and realistically most auto-closed PRs stay closed. There's no need to open a new PR either way.

CONTRIBUTING.md has the full reasoning, but in short:

• We're a small team with very little capacity to review community PRs right now.
• Many recent PRs are AI-generated with little human review, and reviewing one carefully still costs a maintainer as much time as it ever did. A well-described issue is usually more useful to us than the code.

Maintainers: reopen, remove missing-issue-link, or add bypass-issue-check to override.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	⚠️ Failed 2026-10-20T13:09:54.092921Z	63888df	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.