Hash crypto & JWT
Refresh Tokens Without a Database: State and Revocation
Compare stateless refresh credentials, rotation records, revocation, shared caches, and managed authorization servers before removing persistent storage.
Separate no application database from no server state
An application can avoid maintaining its own token database by using an authorization server that manages sessions and refresh credentials. That does not make the overall system stateless. The state may live in another service, a shared cache or a dedicated session store instead of the application's relational database.
A self-contained signed refresh credential can carry information that the issuer checks without looking up the original token record. But the signature alone does not answer whether that credential was already used, revoked or replaced. Decide which of those behaviors the system must provide before removing storage.
Map each requirement to the information it needs
| Requirement | Information the system must have |
|---|---|
| Verify a self-contained signature | A trusted algorithm and applicable verification key |
| Reject an expired credential | A validated lifetime claim and an appropriate clock |
| Detect reuse after rotation | Evidence that the credential or its family was already consumed |
| Revoke one session promptly | A way to distinguish that session from other otherwise valid credentials |
| Survive process restart | State or policy that remains available after local memory is lost |
| Coordinate several servers | A consistent view or protocol for the relevant session transition |
Putting a unique identifier inside a JWT supplies an identifier. It does not supply a history of how that identifier has been used. If two copies of the same unexpired credential arrive at different servers, purely local signature checks cannot distinguish the legitimate first use from a later replay.
Understand why rotation needs coordination
With rotation, a refresh credential is replaced after an accepted exchange. Detecting an old credential's reuse requires the server to know that the earlier exchange occurred. An in-memory Map can demonstrate the transition in a single process, but it loses records on restart and is not automatically shared by another instance.
A shared store can make the consume-and-replace decision atomic. The exact data model and retention policy depend on the provider and threat model. Storing only hashes or other protected references may reduce exposure, but the system must still implement the comparison and transition correctly.
The OAuth security guidance on refresh tokens describes replay protections, including sender-constrained approaches and rotation. These are protocol designs with conditions, not interchangeable labels that can be added to an otherwise unchanged token generator.
Be precise about logout and permission changes
Deleting a token from one client's storage prevents that client from using its local copy. It does not invalidate another copy already held elsewhere. If the server accepts the credential based only on signature and lifetime, that copy can remain usable until the acceptance policy changes or the credential expires.
Rotating a signing key can invalidate a broad set of tokens, but it is usually much wider than revoking one session. A per-user version, session denylist or current-account check introduces state somewhere. That may be an appropriate choice; describe it honestly instead of calling the design completely stateless.
Token revocation defines a protocol for supported authorization servers. Verify how revocation propagates to access tokens and resource servers in the actual system. A successful revocation response is not a universal guarantee that every independently validated access token immediately stops working.
Choose a storage boundary the team can operate
For a small application, a managed identity service can move session-state operations out of the application code. For a self-hosted authorization service, a reliable shared store may be simpler than trying to reconstruct one-time behavior from signed strings alone. Consider outages, backups, retention and multi-instance deployment.
If the chosen design intentionally accepts limited revocation capability, document the consequence and bound credential lifetimes appropriately. Do not market it as providing immediate single-session revocation and replay detection unless those behaviors are implemented and tested.
Test the events that a single happy path hides
Test replay after a successful refresh, simultaneous requests to different instances, a process restart and revocation of one session while another remains active. These cases reveal whether the chosen state boundary supports the advertised behavior.
The JWT Decoder can inspect a synthetic credential's claims, but no local decoding result proves that rotation or revocation exists. Those properties belong to the authorization system and must be evaluated through its actual session transitions.
Related guides
Implement the renewal control flow around an authorization server, avoid concurrent refresh races, and retry an API operation only under a bounded policy.
Trace an illustrative access-token and refresh-token exchange, keep each credential at its intended endpoint, and handle replacement tokens carefully.
Understand why editing a JWT invalidates its signature, how an issuer replaces claims, and what happens to previously issued tokens after a role change.