stacklok / toolhive / 42800117903

73%

Build Type

push

github

Committed by web-flow

Commit Message

Refuse client assertions without a positive exp (#7087)

fosite treats an exp of 0 in a private_key_jwt client assertion as
absent and accepts the assertion. It then passes time.Unix(exp, 0) to
the storage backend as the deadline of the jti replay marker. The
backends record a deadline in the past as an already-expired marker, so
the same assertion can be presented again and again. An exp near the
maximum int64 wraps in time.Unix to a deadline in the past, and an
assertion presented in the last second of its life passes fosite's whole
second check while its marker is already gone.

All of these end as a deadline in the past at the storage call, so the
fix judges that value instead of reading the JWT a second time. The
storage handed to fosite's provider is wrapped, and its
SetClientAssertionJWT refuses a deadline that is not in the future with
invalid_client. fosite returns that error unchanged, so clients see the
same 401 as for any other bad assertion. The handler factories keep the
unwrapped storage, and the wrapper forwards PARStorage when the backend
has it.

The rule lives in one function, ValidateClientAssertionExp. The Memory
and Redis backends call it too, so an embedder that builds its own
provider over them gets the same refusal. Redis no longer deletes the
reservation for a past deadline: that deletion was the replay hole. A
refused assertion leaves its 30 second reservation in place.

Co-authored-by: Mecatl <noreply@mecatl.dev>

Coverage Stats

26 of 26 new or added lines in 4 files covered. (100.0%)

2 existing lines in 2 files now uncovered.

93991 of 129109 relevant lines covered (72.8%)

857.38 hits per line