Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Remove JWT on logout in Spring Application

We are trying to follow this code base for our Spring REST based application. spring-boot-jwts

The issue is that we are not able to remove the JWT token during logout from server. When we checked on net we came to know only approach for this is Blacklisting the JWT tokens as given in this Blacklisting. Is it so?

We are bit new to token based authentication, please let us know if there's a solution like expiring the token on logout calls or something.

like image 659
pranav Avatar asked Feb 20 '18 17:02

pranav


People also ask

Is JWT token should be invalidated on the server after logout?

We'll also want to generate a refresh token to maintain the same user session (refreshing the expiration) as long as they're logged in. Once they're logged out, we can let the JWT token expire, and invalidate it. That being said, we'll need to map a device as well as the refresh token to a user's session.

How do I manually expire JWT token in spring boot?

This claim provides a unique identifier for the JWT. When a JWT is manually expired you insert the jti into a blacklist. The value should persist into the table until the natural expiration of the token. Now, for each request should also check if jti inside the table; if it's found the access is denied.

How do I terminate a JWT token?

You cannot manually expire a token after it has been created. Thus, you cannot log out with JWT on the server-side as you do with sessions. JWT is stateless, meaning that you should store everything you need in the payload and skip performing a DB query on every request.


1 Answers

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

like image 150
Raf Avatar answered Sep 24 '22 16:09

Raf