Handling refresh token revocation

Question

I've been implementing an authentication flow for an app that I've been making that uses JWTs. When a user is initially logged in or when they register (which immediately logs them in), I provide an access token and a refresh token. Access token expires every t hours but the refresh token never expires. I want to revoke the tokens when the user logs out.

One approach I've heard is that you can store a list of revoked tokens in a database and set a TTL on the document so that the database doesn't consume too much space.

I've also thought about storing a list of active tokens in a database which is sort of the inverse of this but I've heard people say that this is a bad idea but it seems to me that it is the same as storing revoked tokens.

Why would you choose to store blacklisted tokens over storing active tokens? Both require a database search. Both remove the statelessness of JWTs.

Answer 1

I think it's common to store Refresh tokens in persistent storage. It's the Access token you don't want to store. Access token is verified on each call to your API (or whatever else) so you don't want to have that checked in the Db every time. That's where JWT shines because it can verify the integrity of the token without the need to store it on the server.

The refresh token is called once every X hours, when the Access token expires. You can just store it in the Db, and check if it still exists/has been revoked or whatever else logic you want.

Answer 2

A refresh token is given to the application by authorization server to allow offline access, i.e. even if user is not using the app, it can still get access tokens and make API calls. The user will typically tell the app to drop that refresh token by "logging out" or other context specific appropriate user experience. The app just needs to delete the refresh token on its end.

The case about storing refresh tokens is actually about revoking refresh tokens even if the user doesn't log out. For example, there was some vulnerability because of which all previously issued refresh tokens must be revoked. Or the user has an interface using which they can see all apps that have access on behalf of the user and they can selectively deny some apps that access, i.e. revoke their access.

For denying all refresh tokens, you can typically store one timestamp per user and update that when all refresh tokens for that user should no longer me honored.

If you want to give the user selective control over denying certain apps access, then you would store app and some identifier of the refresh token issued. That will allow you to create a UI in which user can see all apps and selectively deny access. (An experience available in Facebook, Microsoft Account, Twitter, etc.)