tegwick
91e3d50907
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 29s
Closes the remaining half of gap G01. The adapter decoded upstream ID-token claims without verifying anything, justified in a comment by a server-to-server TLS boundary that nothing enforced. Operator decision: verify the token rather than police the transport. The hop is to be HTTPS as defence in depth, but KeyCape does not monitor, check or gate on that -- a transport check helps only when it is configured correctly, which is the assumption it was meant to remove. Verification holds regardless of how the token arrived, so no HTTPS validation or opt-in flag is added. HandleCallback now verifies the RS256 signature against Authelia's published keys, the issuer Authelia advertises, KeyCape's own client ID in the audience, and a sane validity window, before any claim is trusted. It fails closed: an unreachable or unparseable key set denies the login. The advertised jwks_uri path is rebased onto the server-side token base URL so split-horizon deployments resolve, with config overrides where that inference is wrong, and an unknown key id triggers one refresh so provider rotation needs no restart. The reusable half lives in internal/jose rather than being copied from authclient's verifier, since duplicated verification is how two copies drift and one misses a fix. Migrating authclient onto it is tracked as KEY-WP-0019-T05, kept separate so it does not destabilise a tested path in this change. Thirteen rejection cases plus algorithm and rotation coverage; with the unverified parse restored all fifteen fail, so they test the fix rather than merely passing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NV9oijZukGyGbRQGGKnK4P Assistant: claude-code Assistant-Model: opus Assistant-Process: 713576@bnt-lap001 Assistant-Session: 384c511d-9bce-4cb8-a676-2aef6c0c8df6
3.8 MiB
Executable file
3.8 MiB
Executable file