Authentication - More secure Refresh Tokens
The Refresh Tokens are used to obtain a renewed Access Token, but in case they become compromised, the attacker will be able to generate any number of Acess Tokens, so in this post we are going to see some methods to work with them in a more secure way.
Refresh Tokens blacklist
We can implement a Refresh tokens blacklist, it should be stored in persistence (Like a database), so if any Refresh Token is compromised, we can add it to this blacklist.
Also we need to update the endpoint /refresh to check if the Refresh Token in the HTTP request is blacklisted.
We can implement this blacklist as a independent table in a database, or we can update the Refresh Token entity adding this property:
{
"revokedAt": "2022-04-10T12:08:20+00:00"
}
revokedAt: [Nullable Date property] Used to store the revocation date of the Refresh Token.
Refresh Tokens Auto-revocation
This method uses the Refresh Tokens blacklist, so it should be previously implemented.
This method consists in update the endpoint /refresh to check if the Refresh Token in the HTTP request is blacklisted or if it has already been used, so if this is the case we should revoke the entire family of Refresh Tokens (All of those that have been generated by it), also we can invalidate all the valid Refresh Tokens created by the User or by that IP.
If the Refresh Tokens auto-revocation has been configured in the identity server, the Refresh Tokens can be safely stored in the local storage of the client, because if they are compromised, the threat would not be dangerous as it would be if the Refresh Tokens auto-revocation is not implemented.