DEV Community

Discussion on: Remaining Stateless - A more optimal approach

Collapse
 
ivomeissner profile image
Ivo Meißner

This is a great write up! For additional security, I would recommend adding invalidation of the refresh token on refresh so that each token can only be used once. I usually store the refresh token in the DB on the server-side. You can even add the IP address(block) or the user agent and reject the token refresh if they don't match...

Collapse
 
mr_cea profile image
Ogbonna Basil • Edited

@ivomeissner is that more like blacklisting the previous refresh token when a new one is generated in redis or using browser finger printing to check the IP address on incoming requests?

Collapse
 
ivomeissner profile image
Ivo Meißner

Yeah, you can do both. I usually always store it in the DB, so that I can also revoke access by deleting the refresh token in the DB in case someone wants to change passwords (device stolen etc.). Otherwise, it's a lot harder to invalidate the refresh tokens and might have an impact on other users (for example invalidate all tokens that were issued before x).

Thread Thread
 
mr_cea profile image
Ogbonna Basil

Thank you