Part of the Refresh Token Design series. The Question the Last Post Left Open A refresh arrives carrying a device proof that does not verify. Two things can produce it, and the request looks identical either way. A browser that lost its key and generated a new one, which is ordinary and frequent. Somebody holding a copy of the refresh token, who cannot sign because the key never left the machine it was made on. ...
Part of the Refresh Token Design series. I Have Shipped the Other Answer Twice Two systems I have written and published about keep a table of spent refresh tokens and treat a repeat as an attack. One uses a used_refresh_tokens table and a queue in the client. The other hashes the token and rejects the second presentation outright. That is the standard advice and I still think it is defensible. This post is about what happens when you take it out, which the previous post in this series did, and what that actually costs once you look at the code rather than the intention. ...
Part of the Refresh Token Design series. Signing In Is Not a Boolean Most auth code treats the session as a switch. Either somebody is in or they are not. Real sign-in has states in between, and each one needs a session that exists and reaches almost nothing. Somebody types a correct password and owes a second factor. They are not signed in, but they have to be able to call the route that lists their factors, the route that sends a code, and the route that verifies one. Those routes need to know who is answering, which means a session, which means a token. ...
Part of the Refresh Token Design series. The Problem With Single Use Single use refresh tokens are the standard advice and the advice is right. A refresh token that works twice is a refresh token somebody can steal and use behind you. The trouble is the failure mode when a response goes missing. A client sends its refresh token. The server rotates, writes the new pair, and answers. The answer never arrives, because the tunnel dropped, the phone changed cell, the laptop lid closed. The client still holds the old token, and the old token is now spent. It retries, gets refused, and the person is looking at a login screen because of one lost packet. ...
What This is a nine part series on refresh token rotation, session records, and device binding, built around one claim: the JWT in your auth system is not a stateless assertion, and treating it as one is what makes the design complicated. A JWT is three useful properties. It expires on its own, it cannot be modified without invalidating the signature, and it can carry data you put there. That is a good envelope. It is not an authority on whether the person holding it should still be let in. ...