A bearer token outlives revocation of the key that authorized it
- Dominant language
- Rust
- Stars
- 3
- Forks
- 0
- Avg merge
- 1d 42m
- Merged PRs (30d)
- 11
Description
`Identity::verify_token` (`rs/cyphr-server/src/auth/token.rs:125-149`) accepts a bearer token on three checks and no others: the signature verifies against this identity's key, `typ` equals the bearer-token type, and `exp` is in the future. It never reloads the subject's principal and never consults the death-set.
The consequence is that revoking a key does not end a session already authorized by it. A token issued before the revocation keeps working until it expires, because nothing on the verification path looks at principal state. Exposure is bounded by the token TTL rather than by the revocation.
That may well be the intended design — a short TTL in place of a revocation list is a legitimate trade, and the bound is real. The problem is that it is currently a property of the code that nobody has written down or tested, so it is neither guaranteed nor prevented. A future change to `verify_token` could tighten or widen the window without anything failing.
The behaviour appears to be untested. The nearest existing coverage is `revoked_key_refused_at_login_sibling_survives` (`rs/cyphr-server/tests/naked_revoke.rs:939`), which establishes that a revoked key is refused **at login** and that a sibling key still works — it never issues or verifies a bearer token across a revocation. Worth confirming rather than taking on trust:
```
grep -rn "verify_token" rs/cyphr-server/tests/
grep -rln "revoke" rs/cyphr-server/tests/
```
What would close this is a test that issues a token, revokes the key that authorized it, and asserts the resulting behaviour — whichever behaviour is decided to be correct. Deciding that first is the point: the useful outcome here is a stated guarantee about what a bearer token means after revocation, with a test that holds the codebase to it, rather than a silent property discoverable only by reading twenty-five lines of verification logic.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading Identity::verify_token in rs/cyphr-server/src/auth/token.rs:125-149 and run the two grep commands from the issue to confirm existing coverage. Compare with revoked_key_refused_at_login_sibling_survives in rs/cyphr-server/tests/naked_revoke.rs:939, then decide and document the post-revocation bearer-token guarantee and add a test covering issuance, revocation, and verification.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- authentication, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100