Skip to content

auth: add AllowMissingExpiration option to RequireBearerTokenOptions#971

Open
BorisTyshkevich wants to merge 1 commit into
modelcontextprotocol:mainfrom
Altinity:auth-allow-missing-expiration
Open

auth: add AllowMissingExpiration option to RequireBearerTokenOptions#971
BorisTyshkevich wants to merge 1 commit into
modelcontextprotocol:mainfrom
Altinity:auth-allow-missing-expiration

Conversation

@BorisTyshkevich
Copy link
Copy Markdown

Summary

  • Add an AllowMissingExpiration bool field to RequireBearerTokenOptions that opts the middleware out of the existing tokenInfo.Expiration.IsZero() reject.
  • Default false preserves the existing strict behaviour: every TokenInfo must carry an Expiration.

Motivation

Some IdPs emit session-bound bearer tokens that do not carry a standalone exp claim — the token's lifetime is bounded by an external session and is not advertised in-band. Resource servers integrating with such IdPs today have to synthesise a fake Expiration from their TokenVerifier callback (dishonest data through the auth layer) or fork RequireBearerToken to bypass the check.

This option lets the verifier honestly report "no expiration in the token" via a zero Expiration and have the middleware accept it — while still applying the elapsed-validity check for tokens that DO carry an Expiration.

Some IdPs emit session-bound bearer tokens that do not carry a standalone
`exp` claim — the token's lifetime is bounded by an external session and is
not advertised in-band. Resource servers integrating with such IdPs need to
opt in to validating the rest of the token (scopes, signature via the
verifier callback) without requiring the expiration field to be present.

Adds an AllowMissingExpiration bool to RequireBearerTokenOptions. Default
false preserves the existing strict behaviour. When true, a TokenInfo with
a zero Expiration is accepted; non-zero expirations are still checked for
elapsed validity.

Extends TestVerify with a "no expiration with AllowMissingExpiration accepts"
case mirroring the existing strict-reject case.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant