Long story short
, you have to build a mechanism to delete or invalidate a token manually
on logout.
Should I store JWT token or not?
The question you should ask yourself is
- Do I need to store the JWT token in database? If so, why?
The above question will not necessary solve your logout
issue because, you still need a mechanism to invalidate
a token that is stored or not stored in database
.
One of the benefits of not storing
the token in database is that you don't have to worry about deleting
them when (no maintenance or some clean up process)
- They token expire
- Their scopes changes
- The user's (in case of
password
flow, let's not cover other flows
) roles and permissions are downgraded or upgraded in database and hence, what's inside jwt is outdated
- The user is deleted
- The user logged out (Wonder if this is a good enough reason to delete token)
- The tokens is compromised (Tricky one)
- [Add other cases]
Verifying a token's validity?
I am sure you are using the verify
endpoint and it's purpose is to validate whether a token is valid
or not but, will not necessary check all the above scenarios which means you have to either
- Customize the
verify
workflow to add more custom checks
OR
- Before the token is being
verified
for signature validity
, expiry time
, and some other default checks
you can run your own custom checks
and if your custom checks
passed then proceed otherwise you shall not pass!
What are your options then?
Well, besides blacklisting
you could do something as follow
Use in-memory store
Simply store the uniquely-identifying-metadata
of JWT token into redis as key and give it a expiry time
that is same as JWT
token expiry time so that it self-destruct
when the token is expired.
set key {replace_with_jwt_unique_identifier} ex {jwt_expiry_timestamp}
Risk: Redis is in-memory store and the entries are not persisted.
Use database
Don't use Redis or don't want to take the risk. You can use database with a custom database table. A separate table that is either
- Related to JWT record and has a
ON DELETE CASCADE
- Not-related to JWT record and you have to maintain it yourself
When a token is issued also populate this new database table.
Common Remaining steps
When a normal
request comes in with a JWT, use the JWT to query the in-memory
store or database
table to see if record exist.
In case of in-memory
store a simple existence
check is more than enough.
In case of database table
you need to do more checks (i.e. exist and not expired, etc.) and if the checks passed the let the request through, else you shall not pass!
When a logout request
comes in, in case of in-memory
store simply delete the key
and proceed (if found) and in case of database
you could delete the JWT
record which will cascade down to new table.
When to do the custom checks?
Well, you can do it
- First and fore-most using a custom top-level filter or
- You can expand the
verify
endpoint workflow to also do these extra checks
The projects that I work with does not require a token to be invalidated on logout
so I did not have to cross this bridge. I did have to expand the verify
endpoint to make sure a token is valid if all my custom checks
have passed.
Extra reading materials
In addition to tutorial that you pointed out. There are some other SO questions that also discuss a similar issue. See
What if JWT is stolen?
How to destroy JWT on logout?
More how to delete a JWT token?
How to invlidate JWT when password changed
Github issue - how to invalidate JWT
Finally the best for the last - Invalidating JWT Web Tokens