hyperscale-stack / security / 32661849110

92%

master: 92%

Pull #66

github

fix(oauth2): compute expires_in from the server clock

ServerConfig.Now is documented as the clock the server stamps issuance and
expiry with, and every other site honoured it. writeTokenResponse did not:
it measured the remaining lifetime with time.Until, i.e. against the wall
clock, while ExpiresAt came from the injected clock.

With a pinned clock the advertised expires_in stopped describing the token
it shipped with, and a clock pinned far enough in the past put a negative
lifetime on the wire — which RFC 6749 §5.1 does not allow. The stored expiry
was right, so a client trusting expires_in refreshed at the wrong moment
while introspection still reported the token as valid.

serveToken now reads the clock once and passes that instant to both the
grant and the response, so expires_in is exactly the configured TTL. The
value is rounded to the nearest second — truncation advertised a 1h TTL as
3599 as soon as a millisecond elapsed between two clock reads — and an
already-expired token drops the field instead of carrying a negative
lifetime. Refs #64.

12 of 12 new or added lines in 1 file covered. (100.0%)

3914 of 4265 relevant lines covered (91.77%)

12.68 hits per line