How do I implement Refresh Token Rotation?

Question

If I understood the refresh token rotation right, it means that every time we request a new access token, we also get a new refresh token. If a refresh token is used more than once - we invalidate all the refresh tokens that a certain user previously used, and a user has to go through the authentication process again.

1. Does it mean that we need to store all the refresh tokens (all the old ones) in a database?

2. Can't we simply store the last refresh token, only one (that wasn't used yet), and with each request to get a new access token we would check if the refresh token sent in the request is in the database, and if so, we would create a new access and refresh token and overwrite the old refresh token in the database, so that old refresh tokens can't be used to get new tokens?

3. How long should such refresh tokens live?

Berne

Answer 1

1. Yes, but all will usually mean "all in a given time frame". The time frame will depend on your needs - for how long do you want to be able to identify any potential refresh token leaks.

2. You can, but then you don't get any better security than without using token rotation. This is because you never know who used the current token first - the legitimate user, or the malicious one, who stole your token. If it was the latter, then she will now have access to working access/refresh token pairs. The legitimate user will be left with an invalid token.

3. This depends on your requirements, features, security etc. You will usually find information that a refresh token should be valid for a couple of hours (usually up to 8), but I've setups with refresh tokens valid for days or even months.

Enervated

Speaking of the 2nd answer: The legitimate User has credentials to (login) get a new refresh token, so even if some malicious person somehow steals the refresh token and uses it, once the real user logs in - token of the malicious person will be overwritten in the DB (it gets invalidated), and they won't be able to get new access tokens anymore. Does it make sense? – Berne

Sure, but If the legitimate user does not log in for a month, then the attacker has 30 days to do with the stolen account whatever she wants. You shouldn't assume that the user will login again quickly enough to stop the attack. – Enervated

I see the point, but isn't it the same with Refresh Token rotation? If an attacker steals the RT, and then the legitimate user closes the app, the attacker will be able to generate new RT and AT forever? – Berne

Yes, that is true. Refresh token rotation tightens your security, but does not make your app 100% resistant to stolen tokens. – Enervated

Thanks for the answer, I have one last question. If we use the rotation feature, and we request a new AT+RT every 10 minutes, it means that we also have to save the old RT in our DB. Let's say our RT exp time is a week, so each RT will be in the DB for about 10070 minutes (a week minus 10 minutes). If we store each RT generated in that period of time, it will be around 1007 tokens per user, is it okay? Is it what people usually do? – Berne

As far as I know it's how it is usually done. – Enervated

One way to solve this is to have RefreshToken chains. A RefreshToken has 2 parts, a TokenID that does not change, and a Token version that does. E.g., "Id1.V1-sxjfd...", "Id1.V3-irutt...". When you refresh, the Id will be the same, but the value will change to e.g., "Id1.V3-irutt...". This way, you only have to store the latest version of a RefreshToken in the database. When someone uses "Id1.V1-sxjfd...", you can invalidate the RefreshToken chain "Id1.*" – Isochronal