Two more fixes from the device-flow security review:
slow_down interval grew without bound (OidcController):
- Each too-fast poll bumped the persisted interval by 5s with no ceiling, so a
client polling slightly fast — or an attacker spamming a known device_code —
could balloon it (5→10→15→…) past the 10-minute expiry and starve a legitimate
client of its token. Clamp the bump to OidcDeviceCode::MAX_INTERVAL (30s); a
client polling at the advertised interval is never throttled.
Expired device codes accumulated forever (OidcTokenCleanupJob):
- Anonymous callers can create device codes via /oauth/device_authorization, and
expired/denied/abandoned rows were never reaped. Sweep rows past expiry (with a
1-hour grace to stay clear of in-flight redemption); redeemed codes are already
destroyed at token issuance.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Q4ATZHoMCWqvSpE2yYoie
The FK added in b7fa499 defaulted to ON DELETE RESTRICT, which means
OidcTokenCleanupJob#perform would fail when deleting auth codes older
than 7 days if any refresh token (whose expiry is days-to-weeks) still
referenced them. Switch both token FKs to ON DELETE SET NULL so token
rows survive the code deletion with a NULL FK, preserving the audit
trail the cleanup job deliberately keeps.
Add a regression test covering the exact scenario: a 10-day-old auth
code with a token still pointing at it -> cleanup deletes the code,
token survives, token FK is nulled.
Co-Authored-By: Claude Opus 4 <noreply@anthropic.com>
