Expected Behavior
It should be possible to configure a custom java.time.Clock on OAuth2Authorization
(via OAuth2Authorization.Builder), so that Token#isExpired(), #isBeforeUse(), and
#isActive() evaluate against the injected Clock instead of the system clock.
Current Behavior
OAuth2Authorization.Token#isExpired() and #isBeforeUse() compare token timestamps
(expiresAt, nbf claim) directly against Instant.now() / the system clock, with no way
to override this externally.
Context
Writing deterministic tests for token expiry, not-yet-valid (nbf), and revocation/refresh
flows currently requires either Thread.sleep(...), constructing tokens with timestamps
computed relative to Instant.now() at test-build time, or mocking static methods — all of
which are brittle or awkward. Injecting a Clock would make these scenarios reproducible
and independent of wall-clock time.
Expected Behavior
It should be possible to configure a custom java.time.Clock on OAuth2Authorization
(via OAuth2Authorization.Builder), so that Token#isExpired(), #isBeforeUse(), and
#isActive() evaluate against the injected Clock instead of the system clock.
Current Behavior
OAuth2Authorization.Token#isExpired() and #isBeforeUse() compare token timestamps
(expiresAt, nbf claim) directly against Instant.now() / the system clock, with no way
to override this externally.
Context
Writing deterministic tests for token expiry, not-yet-valid (nbf), and revocation/refresh
flows currently requires either Thread.sleep(...), constructing tokens with timestamps
computed relative to Instant.now() at test-build time, or mocking static methods — all of
which are brittle or awkward. Injecting a Clock would make these scenarios reproducible
and independent of wall-clock time.