[woksin]

Summary

DPoP replay protection is more predictable when Redis is slow or a request lacks scope, and the Redis replay store is now covered by specs that run against a real Redis.

Changed

• A valid DPoP proof that lacks the required scope now gets HTTP 403 insufficient_scope without reserving its proof identifier. Successful authorization still requires an atomic replay reservation. (Real-Redis integration spec for the DPoP jti replay store #302)
• The replay-store health check now gives up after a bounded wait and fails closed, rejecting the request, instead of holding requests while Redis is unresponsive. (Real-Redis integration spec for the DPoP jti replay store #302)

[woksin]

Folded items

• l113-302-redis-replay-specs at 111b4ad2cb0010bd9a120ebc2cbd90e4596767c9; cancelled runs: none

Verification

build: train-g-build (2026-11-12T19:39:09.779095Z)
test: train-g-authproxy-specs (2026-11-12T19:41:05.141860Z)
test: train-g-security-specs (2026-11-12T19:42:26.463574Z)

[woksin]

Reviewer notes

• New Source/AuthProxy.Integration.Specs (Testcontainers Redis): cross-replica reservation, Redis restart without replay evidence, replica/Redis clock disagreement, quarantined replay coverage. The project is a test project only when RunRedisReplaySpecs=true, so solution-level dotnet test stays container-free; the new path-filtered Redis replay specs job (part of gate) opts in.
• Local gate on the train head: Release build with warnings as errors, AuthProxy.Specs (6,432) and AuthProxy.Security.Specs (1,595) green. The Redis specs have not run locally; their first run is this PR's CI.
• Code Health: RedisDpopReplayStore.cs 9.58 -> 9.50, when_caching_replay_store_health.cs 10 -> 9.68 (both at or above 9.5, one refactor pass; the added defensive checks and data-driven cases account for the drop).
• Two review rounds (deep, security lens); the second passed with no findings.

[woksin]

Superseded by #342.