4

I recently discovered JWT for token authentication + authorization. I think is very useful to have user info wrapped in the token, so I'm trying to use it in a Java/Spring web project.

At first, my impressions were: if I have all the user data in token I don't need to store it in application DB and I don't need to retrieve user + session information for every service request. This is fantastic and could improve effectively service access performance.

But now I'm having some doubt on JWT "limitation" for my use case. For example: what If the user is disabled by service admin and the last generated token is not yet expired? The user can access to the service even if it is actually not authorized...

Is this a limitation of JWT or am I missing something? Can you clarify my doubt?

davioooh
  • 23,742
  • 39
  • 159
  • 250

2 Answers2

1

JWT is self-contained. One of the advantages is that it does not need server session storage, because digital signature protects the content.

There are several reason to invalidate a JWT token before its expiration time: account deleted/blocked/suspended, password changed, permissions changed, user logged out by admin. Take a look at Invalidating JSON Web Tokens

It is a common need and there are several techniques to apply or combine depending on your use case

  1. Remove the client token

  2. Token blacklist: Store tokens that were between logout & expiry time, mark expired and check it in every request. You need server storage. You can include only the ID, or use the issued_at and check last update to user profile

  3. Expiry times short and rotate them. Issue a new one every few request. The problem is to maintain user logged when there are no requests (for example closing browser)

Other common techniques:

  • Allow change user unique ID if account is compromised with a new user&password login
  • Include last login date to remove old tokens
  • To invalidate tokens when user changes their password, sign the token with a hash of their password. If the password changes, any previous tokens automatically fail to verify. Extend this mechanism with other field of interest to sign. The downside is that it requires access to the database
Community
  • 1
  • 1
pedrofb
  • 37,271
  • 5
  • 94
  • 142
  • In my opinion every option that requires an access to DB invalidate JWT advantages, so I think the 3rd option could be the actual solution to my use case... Thank you – davioooh Aug 04 '16 at 12:34
  • I agree with avoiding DB usage. If you do not expect too many tokens to revoke, you also could use an in-memory blacklist. You only need to set an entry after updating critical data on user and `currentTime - maxExpiryTime last_modified` (no more non-expired tokens sent). – pedrofb Aug 04 '16 at 12:53
0

First of you need DB for storing user's token so you can manually expire token for specific user.

You will find more in this answer:

https://stackoverflow.com/a/31010380/5309525

Community
  • 1
  • 1
Ihor Salnikov
  • 35
  • 6