What Is JWT and Why Should You Use JWT

You have probably heard of JWT or you have maybe even read about it. But you still have absolutely no idea how JWT really works or even why would you actually want to use it.

First I'm gonna tell you what JWT is then I'm gonna talk about why you should use JWT and finally I'm gonna show you exactly how JWT works and how you can use it yourself

Before I go into details of exactly how JWT works we need to understand what JWT is used for. So, JWT is just for authorization not authentication.

Authentication

When a user successfully logs in using their credentials, an ID token is returned. According to the OpenID Connect (OIDC) specs, an ID token is always a JWT. Simply you take username and password from user and authenticate to make sure that username and password is correct is correct. It is just like logging a user in.

Authorization

Authorization is actually making sure that the user sends request to your server is the same user that actually logged in during authentication process. This is called authorizing that this user has now access to this particular system.

It is normally done by using session. For example, you have a session ID, that you send down in the cookies of the browser and everytime the client makes request they send that session ID up to the server and the server checks its memory says okay what user has that session ID, it finds that user and then it does the authorization.

But JWT instead of actaully using cookies it uses a JSON Web Token that JWT stands for to do the authorization. Let's see it by figure below

Session Login

So, In above chart we have a traditional user login system that uses session and cookies to store the user. So the first thing that happens is the user actually logs in from the browser by posting the login service with their email and password and as soon as that gets to the server what's going to happen is the server is going to do the authentication to make sure that user is correct. Now if that user is correct with email and password the server stores that user inside the session which is stored inside the memory of server and they're going to get a unique ID that corresponds with that heart in memory. Then the server send that ID back to browser using a cookie so that the browser always has that session ID that it send up to the server every single time it makes request.

For example ,now in second line when the client(browser) needs to make another request, for example it wants to go to a new page in application that session ID gets sent along with the cookie that it corrosponds with so since it's a cookie it gets send alone to the server.

Now at the server what happens is it's going to do the calculation is going to go into the session memory and it's going to check do I have something in memory that corrosponds to this particular ID that gets sent to me if so then it's going to say, this is the user that corresponds with that ID and it has access to that user store to store that user in the session memory.

So now the application knows this is the user I'm working with, is this user authorized to access this information if he is authorized then it sends the response back to the browser saying ok everything's good. Here's the information you were looking for.

JWT Login System

Now we have the JWT method of authentication. It works very similar to session method in begining. We make a post request with our email password and we send that along to that server just like before but instead of storing information on the server inside session memory what happens is the server creates a JSON web token (JWT) and it actually ecnodes it and serializes that assigns it with its own secret key so the server knows that if you tamper with it than its invalid. It can actually check that based on the fact that it's assigned with a secret key. Then it takes that JSON web token and sends it back to the browser and notice the main difference here, nothing is sotred on server. The server doesn't store the user nothing actually happens on the server. This JWT has all the information about the user built into it. So it send that JWT back down to the browser and the browser can choose to store that however it wants.

For example you could do cookie storage and it work similarly to session method. But anyway that happens the client(browser) is then going to send a request to the server and they're gonna make sure to include that JSON web toke so that it knows what user is autenticating with. Now the server what it does is it's signed to that JSON web token with its own secret key so what it does is it verifies that this JSON web token has not been changed since the time that it signed it because if for example the client changed it and changed the user information in that JSON web token the server will now know and they can say that it's invalid. But if for example nothing actually got tempered with the JSON web token is correct now what happens is it just deserializes that JSON web token and it says okay this is the user information it's stored in that token already so it knows exactly what do with that user. Now if that user is authorized to use that resource it'll send that response back down to the client.

Difference between Session and JWT method

Now the main difference you will notice between above two methods is that, in the session version the information about user is stored on the server so the server actually has to do a lookup to find the user based on the session ID but with JWT the JSON web token what happens is the user information is stored in the actual token which means it's stored on the client and the server doesn't have to remember anything which is great because it means you can use the same JSON web token across multiple servers that you run without having to run into problems where one server has a server has a certain session and the other server doesn't.

Security

The information contained within the JSON object can be verified and trusted because it is digitally signed. Although JWTs can also be encrypted to provide secrecy between parties, Auth0-issued JWTs are JSON Web Signatures (JWS), meaning they are signed rather than encrypted. As such, we will focus on signed tokens, which can verify the integrity of the claims contained within them, while encrypted tokens hide those claims from other parties.

In general, JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA (although Auth0 supports only HMAC and RSA). When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.

Before a received JWT is used, it should be properly validated using its signature. Note that a successfully validated token only means that the information contained within the token has not been modified by anyone else. This doesn't mean that others weren't able to see the content, which is stored in plain text. Because of this, you should never store sensitive information inside a JWT and should take other steps to ensure that JWTs are not intercepted, such as by sending JWTs only over HTTPS, following best practices, and using only secure and up-to-date libraries.