What Is a Jwt Token, and How Do We Use It?
This article will answer your questions like you still have no idea how JWT works or why you want to use it. Simply This is something related to the security of your software. So it’s very important to know these things. First, I’m telling you what JWT is, then I will talk about why you should use JWT, and finally, I will show you exactly how JWT works and how you can use it yourself.
Authorization vs Authentication
JWT is just for authorization, not authentication. They’re slightly different from authentication. In authentication, you’re taking the username and the password and authenticating to ensure that the username and password are correct. It’s like logging a user in. But authorization ensures that the user who sends the request to your server is the same user who logged in during the authentication process. It’s authorizing that this user has access to this particular website. That is normally done by using a session. For example, you have a session ID that you send down in the cookies of the browser and then every time the client makes your request, they send that session ID up to the server, and the server checks its memory and says ok, this user has a valid session ID. It finds that the user then does the authorization to ensure the user has access. But JWT, instead of using these cookies, uses a token.
Traditional user login system that uses sessions and cookies to store the user. So the first thing that happens is the user logs in from the client with their email and password. As soon as that gets, the server does the authentication to ensure that that user is correct. If that user is correct, the server store that user inside the session and get a unique ID. The browser always has that session ID that it sends to the server whenever it requests. So now the application knows this is the user I’m working with and they are authorized to access this information. It sends the response to the browser saying, " ok, everything’s good. Here’s the information you were looking for.
Another form of authorization we have here is JWT.
Instead of storing information on the server as session memory, the server creates a JSON web token. This JWT encodes with its secret key. So the server knows it’s invalid if you tamper with it. It can check that based on the fact that it’s signed with a secret key, and then it takes that JSON web token and sends it back to the browser. The main difference here is nothing is stored on the server. This JWT has all the information about the user-built into it. Then the client sends a request to the server that includes that JSON web token so that it knows who the user is authenticating with. The server verifies that this JSON web token has not been changed since it was signed.
How JWT signs its tokens and how can it store the user information?
Here we have two different panes. On the Left, we have the encoded version of our JSON web token. You send this to and from the client, which is how you authorize the user for different resources.
On the right, we have the decoded version of that JSON web token with three distinct parts. It has a header that determines your algorithm to encode and decode. Then it has the payload, which will be all the information you store in the token and lastly, we have the signature that allows us to verify that the client hasn’t changed the token before it gets sent back.
- Header: Determining our algorithm and our JWT token type.
- Payload Data: You can put anything you want.
- Verify Signature: Verify that the user did not change the token.
Why should We use JWT?
Let’s take a look at a very simple example. Here we have two different servers; we have a bank that owns a server that runs all their banking applications. They also own a separate server, which takes care of their retirement plans. That allows people to invest and do retirement plans on a separate web application. They want their users that log in to the bank also to be able to be automatically logged into the retirement account, so when they switch from the bank to the retirement server, they don’t want the user to have to re-log back.
If the client makes a request here to the bank and does all their banking stuff, they finally get to the point where they want to access the retirement information and if you have a normal session-based server. Your session is stored here inside the bank and not inside the retirement server, so your user needs to log back in because the session ID from the client is not found in the retirement server. Still, when you’re using JWT if you share the same secret key between both your bank and your retirement server, then all you need to do is send the same JWT from the client to both of them, and you’ll be authenticated both times without having to relog.
These are the things you need to know about JWT tokens. I hope you got a clear idea about JWT tokens.
Happy Coding !!!!
Found this post useful? Kindly tap the 👏 button below! :)
