78 lines
3.3 KiB
Markdown
78 lines
3.3 KiB
Markdown
# Phase 7.1: Security — Session Revocation on Privilege Change - Discussion Log
|
||
|
||
> **Audit trail only.** Do not use as input to planning, research, or execution agents.
|
||
> Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.
|
||
|
||
**Date:** 2026-06-05
|
||
**Phase:** 07.1-security-session-revocation-on-privilege-change
|
||
**Areas discussed:** Current-session behavior, Scope (CR-01..03), API response + frontend UX
|
||
|
||
---
|
||
|
||
## Current-Session Behavior
|
||
|
||
| Option | Description | Selected |
|
||
|--------|-------------|----------|
|
||
| Revoke all, including current | Cleanest security posture — matches GitHub, Google. Attacker cut off immediately. User must re-login within 15 min (access token TTL). | |
|
||
| Exclude current session | Revoke all OTHER sessions, keep the current one alive. More user-friendly; requires reading and hashing the current refresh cookie to exclude it. | ✓ |
|
||
|
||
**User's choice:** Exclude current session
|
||
**Notes:** No follow-up needed — clear preference.
|
||
|
||
### Implementation mechanism
|
||
|
||
| Option | Description | Selected |
|
||
|--------|-------------|----------|
|
||
| Read raw cookie, hash it, match to DB | Read `refresh_token` cookie, compute SHA-256, pass as `skip_token_hash` to `revoke_all_refresh_tokens`. Consistent with how `rotate_refresh_token` already works. | ✓ |
|
||
| Pass DB row ID | Look up the RefreshToken row during the request, pass its UUID to exclude. More explicit but needs a new helper. | |
|
||
| You decide | Let the planner choose the cleanest approach. | |
|
||
|
||
**User's choice:** Read raw cookie, hash it, match to DB
|
||
|
||
---
|
||
|
||
## Scope: CR-01..03
|
||
|
||
| Option | Description | Selected |
|
||
|--------|-------------|----------|
|
||
| Only CR-01..03 | Three missing `revoke_all_refresh_tokens()` calls. Each ~2 lines. Fast, contained blast radius. Other issues deferred to 7.2–7.4. | ✓ |
|
||
| CR-01..03 + JTI revocation | Also add JTI claims + Redis-based access-token revocation. Much larger change. | |
|
||
| All CONCERNS.md issues | CR-01..03 + JTI + ES256 + token fingerprinting. Major auth rewrite, 3–4 plans. | |
|
||
|
||
**User's choice:** "I want to focus now on CR-01..03 but I want you to add a 7.2-4 for the other three concerns right now."
|
||
**Notes:** Phases 7.2 (JTI), 7.3 (ES256), 7.4 (token fingerprinting) added to ROADMAP.md as part of this session.
|
||
|
||
---
|
||
|
||
## API Response + Frontend UX
|
||
|
||
### Response shape
|
||
|
||
| Option | Description | Selected |
|
||
|--------|-------------|----------|
|
||
| Add `sessions_revoked` count | Return `{"message": "...", "sessions_revoked": N}`. Minimal change, useful signal for frontend. | ✓ |
|
||
| Silent revocation | Don't change response shape. Revocation happens transparently. | |
|
||
|
||
**User's choice:** Add `sessions_revoked` count
|
||
|
||
### Frontend handling
|
||
|
||
| Option | Description | Selected |
|
||
|--------|-------------|----------|
|
||
| Show toast notification | "Other sessions have been terminated." — shown briefly when `sessions_revoked > 0`. | ✓ |
|
||
| No frontend change | Ignore `sessions_revoked` in response. Backend-only phase. | |
|
||
|
||
**User's choice:** Show toast notification
|
||
|
||
---
|
||
|
||
## Claude's Discretion
|
||
|
||
None — all areas were resolved with explicit user preferences.
|
||
|
||
## Deferred Ideas
|
||
|
||
- **Phase 7.2**: JTI claim + Redis access-token revocation (closes 15-min grace window)
|
||
- **Phase 7.3**: ES256 algorithm upgrade (HS256 → ECDSA P-256)
|
||
- **Phase 7.4**: Token fingerprinting / `fgp` claim + validation
|