Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
SecurityStampValidator currently validates when the current time minus the cookie's IssuedUtc is greater than SecurityStampValidatorOptions.ValidationInterval.
A separate machine may trigger reauthentication on a regular cadence close to that boundary. Examples include a browser scheduling SignalR authentication refresh or a request being handled by a different server than the one that issued the cookie. Timer rounding, request latency, and clock differences can cause the request to arrive slightly before the validation interval. The security-stamp check is then skipped until the next scheduled reauthentication cycle, potentially delaying revocation substantially.
Describe the solution you'd like
Investigate whether Identity security-stamp validation should allow a small early-validation window, similar to clock-skew handling elsewhere. Conceptually, a request arriving shortly before ValidationInterval would be allowed to perform the stamp check instead of waiting for another full cycle.
For example:
var validationThreshold = Options.ValidationInterval - validationClockSkew;
validate = timeElapsed >= validationThreshold;
The design should consider whether the skew is an internal framework policy or configurable, how it behaves when ValidationInterval is shorter than the skew, and the impact of slightly more frequent database checks.
Additional context
This came up while integrating Blazor Identity with SignalR authentication refresh in #68663 on top of #68676. The current prototype uses a 40-minute maximum authentication expiration so SignalR's five-minute refresh lead causes reauthentication around minute 35, safely after Identity's default 30-minute validation interval. An Identity-level early-validation window could make boundary-based integrations less sensitive to timer and clock differences.
Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
SecurityStampValidatorcurrently validates when the current time minus the cookie'sIssuedUtcis greater thanSecurityStampValidatorOptions.ValidationInterval.A separate machine may trigger reauthentication on a regular cadence close to that boundary. Examples include a browser scheduling SignalR authentication refresh or a request being handled by a different server than the one that issued the cookie. Timer rounding, request latency, and clock differences can cause the request to arrive slightly before the validation interval. The security-stamp check is then skipped until the next scheduled reauthentication cycle, potentially delaying revocation substantially.
Describe the solution you'd like
Investigate whether Identity security-stamp validation should allow a small early-validation window, similar to clock-skew handling elsewhere. Conceptually, a request arriving shortly before
ValidationIntervalwould be allowed to perform the stamp check instead of waiting for another full cycle.For example:
The design should consider whether the skew is an internal framework policy or configurable, how it behaves when
ValidationIntervalis shorter than the skew, and the impact of slightly more frequent database checks.Additional context
This came up while integrating Blazor Identity with SignalR authentication refresh in #68663 on top of #68676. The current prototype uses a 40-minute maximum authentication expiration so SignalR's five-minute refresh lead causes reauthentication around minute 35, safely after Identity's default 30-minute validation interval. An Identity-level early-validation window could make boundary-based integrations less sensitive to timer and clock differences.