2

I have implemented JWT based security in a test Core Web API REST project, it is working fine but I am not sure that I see the benefit of this. The web says JWT is good because it's lightweight and can be used to verify that the source of data but in my implementation:

  • The client first provides a username and password to authenticate
  • If user + pwd is ok the a token is returned and every subsequent call to the api uses that jwt token (instead of the username and password) to authenticate.

This is fine but why not just use the username + password on every call to the api (and skip the complication of managing the token)? In fact in my case there's additional complications because I now have to factor in an expiry date (of the token) that resides outside of my system.

Can someone explain what I'm missing here?

A_L
  • 1,116
  • 2
  • 11
  • 25

1 Answers1

1

One of the main benefits and motivations for using JWT is that it allows your server side application to push all session state information outside of the application. That is, in a theoretical limit, a JWT implementation is actually stateless.

To directly answer your question, we can compare the workflows for what happens when username/password is submitted in every request versus submitting a JWT.

First, a JWT contains a claims section, which is typically written by the issuer of the token, i.e. the server side application. One of the fields is called exp, and contains the expiry time of the token. One property of JWT is that it is not possible for the user to tamper with them. This is enforced via a checksum, which would change if any part of the JWT changes. Taken together, this means that the user cannot alter the expiry time (or any other claim), and the server can implicitly trust this time. When the user submits a request with a JWT, in theory all the server has to do is just check exp to see if the token still be valid. That is, the session state actually lives outside the application, at least in theory.

In contrast, when the user submits a username/password each time, the server has no way of knowing what to do just based on that information. Rather, the server has to maintain the session state itself, and this can be costly both in terms of memory and performance.

In practice, JWT is never completely stateless, but, using a good implementation, it is usually possible to get the memory footprint very small, requiring only a bit of space in a cache (e.g. Redis or a similar tool).

Tim Biegeleisen
  • 502,043
  • 27
  • 286
  • 360
  • Thanks Tim, so IIUC I can store a bunch of stuff in the token and use just the token for post-authentication calls which will save me reading the database to lookup the user and check password etc. every time? That is fine but surely I would need to check the database anyway (eg. to see if the user has been disabled) since the token was generated - even if the token expiry is only one hour I would still need to check this so would I really gain any advantage here? – A_L May 06 '19 at 13:17
  • You would still gain an advantage, because you would use a cache, not the database, to maintain e.g. a blacklist of users. If you structure your JWT architecture properly, you can usually find a way to keep that blacklist relatively small (e.g. 1-5% of the total number of your users). – Tim Biegeleisen May 06 '19 at 13:53
  • Thanks for the input. I'd need to revisit my design to see how to handle the various cases, still think I'd end up doing db calls...Another complication is invalidation - a good read here for anyone interested (actually one reply asks a very similar question to mine.) https://stackoverflow.com/questions/21978658/invalidating-json-web-tokens – A_L May 07 '19 at 11:36