refactor(auth): validate Sentinel tokens locally - #17
Conversation
BK1031
commented
Sep 10, 2026
- Validate Sentinel access tokens locally with cached Sentinel JWKS keys
- Enforce RS256 signatures, expiration, and the Vault audience
- Refresh signing keys on unknown key IDs with rate limiting
- Keep Vault available with cached keys during Sentinel outages
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d9cff9df12
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if key := cachedSigningKey(kid); key != nil { | ||
| return key, nil | ||
| } |
There was a problem hiding this comment.
Refresh cached keys periodically to honor key revocation
When Sentinel removes a compromised or retired key while continuing to use already-cached key IDs, this early return prevents Vault from ever fetching the updated JWKS; refreshes occur only for an unknown kid. Tokens signed with the removed private key therefore remain accepted until the process restarts or an unrelated new key ID triggers a refresh, and an attacker holding that key can choose a far-future expiration. Add a bounded cache lifetime or background refresh while retaining stale keys only when a refresh actually fails.
Useful? React with 👍 / 👎.