hyperscale-stack / security / 38008266437

95%

push

github

fix(oauth2): enforce the refresh-token rotation the profile requires

* fix(oauth2): force refresh-token rotation under the BCP and 2.1 profiles

Profile20BCP, the zero value, and Profile21Draft advertise mandatory
refresh-token rotation, yet the refresh_token grant rotated only when
grant.Config.RotateRefreshTokens was set and a RefreshTokens generator
was present; Profile.RequiresRefreshRotation had no caller outside a
test. The zero configuration therefore answered a refresh with a new
access token, no replacement refresh token, and a presented token that
stayed live, so it could be replayed until it expired. With the flag set
but no generator, even Profile20 dropped the requested rotation silently.

The grant now decides rotation before minting anything, the way
authorization_code applies the profile to PKCE: the profile can only
tighten RotateRefreshTokens. Under BCP and 2.1 every exchange consumes
the presented token and returns a new one in the same family, and a
replayed token is refused with invalid_grant and revokes the family
(RFC 9700 §4.14.2). A rotation that cannot be honored, for want of a
RefreshTokens generator, fails with server_error carrying the new
grant.ErrRotationRequiresGenerator as cause, before any token is
generated or persisted. The guard runs after request validation, so a
misconfigured server still answers invalid or replayed tokens precisely
and still revokes a reused family.

Non-rotating refresh tokens remain an explicit Profile20 choice. The
example drops its now-redundant RotateRefreshTokens, and the godoc, the
security considerations and the CHANGELOG describe the mandate. Refs #78.

* feat(oauth2): refuse at NewServer a refresh grant that cannot rotate

The refresh_token grant now fails closed when it has to rotate without a
RefreshTokens generator, but a server wired that way still booted and
only broke on the first refresh, answering server_error to every client.
The mismatch between the grant and the profile is ... (continued)

28 of 28 new or added lines in 2 files covered. (100.0%)

3936 of 4287 relevant lines covered (91.81%)

13.22 hits per line