Token revocation is part of access governance

What the public implementation shows

Guevara models tokens, exposes refresh and revoke commands, lists user tokens, and runs an InvalidateExpireTokens background job.

Token lifecycle is stored and administered inside the control plane rather than delegated entirely to stateless signature validity. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleIssuing a token is only the first event in a governed access lifecycle.

The decision behind the mechanism

Persisted lifecycle state enables deliberate revocation and operational visibility across user access.

A cryptographically valid token can remain usable after a user role changes, a device is lost, or access must be terminated immediately. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Store revocable token lifecycle state.
• Expose user and administrator revocation paths.
• Invalidate expired records on a monitored schedule.
• Re-evaluate access after material role changes.

How the control should be operated

Security operations should see token owner, type, issue and expiry times, revocation state, last relevant action, and invalidation job health.

Access can be withdrawn as an institutional action instead of waiting for passive expiry. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.