Ooh! Cookies!

Ooh! Cookies!

This is part 2 of a two-part series about authentication and concepts around it.

First of all, if you haven't read Part 1, "Is that really you?", STOP! Go read it right now! What are you still waiting for? GO!

If you got to this point, congratulations, either you read the other article or you are a little rebel. I like you either way. So let's talk about JWT and Cookies. Ok, I'll start with the one with the cool name. JWT sounds like a slur anyway.

Cookies

Cookies EVERYWHERE! Every single website you access nowadays asks you to accept its cookies policy. But what are they? Cookies are text files with small data. Like a username and password storage. The neat thing is that instead of them storing your data in their server, they store it in your computer and cellphone. They normally contain data about how much time you spent browsing their website, or if you added a product to your cart and immediately removed it because there is no way you can justify buying a Pikachu desklamp, no matter how cute it is.

That sounds like a huge invasion of privacy and sometimes it is. Like it or not, a bunch of websites monitor you and gather behavior data to learn more about you to sell you better products. Yes, there is a line between what's acceptable and what isn't. The Social Dilemma is a great conversation starter about internet surveillance.

I'm here to tell you that cookies don't have to be bad. Cookies allow you to close a website, and when you access it again, your chosen products are still in the cart. They can help you automatically log in, instead of trying 5 different passwords before clicking the "Forgot my password" button. They were designed to improve the user's experience.

JWT

DID YOU KNOW? JWT stands for JSON Web Token! You didn't? Neither did I, I just googled it. But now there are two more questions: What is JSON and what is a Token?

JSON is a data text format for web applications. It stores information in a key-value manner, such as:

{
    "employer": "The Real F.B.I.",
    "firstName": "Phillip",
    "lastName": "Gogin",
    "job": "Head of cool studd and things"
}

Remember when we discussed hash and cryptography? Well, the hash's answer is a token. An array of seemingly random characters, but they have hidden meanings and values.

Now, this is where JWT comes along. It has a set of claims such as who issued the token, how long it is valid for or the user's permissions. The difference now is that we will use a secret. The secret is sort of a password that works as an encryption and decryption key. So only those who have the secret can create and read these JWTs.

Let's go over an example.

Our dude, Phillip Gogin is trying to log into our website. He types his email and password and submits. Our back end is going to check the email, check the password (like we talked about in Part 1) and, if it all checks out, return a JWT.

DataJWT
{

"userId": 87,
"expiration": "20/02/2023 07:00",
"role": "MANAGER"
} | eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJleHAiOjE2NzY2NzI2NjIsInN1YiI6MX0
.VVRzPJyQ45Et_JtgaKDroUL2M_2qQLgx
ZQu3tyoyDbA |

To our front end or to Phillip himself, the JWT means absolutely nothing. He can't read it, and most importantly, he can't edit it. He can only store it, and when he wants to access any data he will send the JWT with any request. The back end will decrypt the JWT, check if Phillip's session hasn't expired and if his role gives him the authorization for the request. If the JWT is in any way corrupted, it will simply deny any requests that need authorization.

JWTs often look like this: xxx.yyy.zzz. When decoded, it has a header, a payload and a signature. The header simply contains the type of token and the signing algorithm. The payload contains the claims (the data we used to create it). The signature makes sure the token wasn't altered.

With all that, we can make a user stay logged in and have his authorizations at hand every time they are needed. If this feels a little confusing or useless, don't worry. It took me a while to wrap my head around it as well. In the next article, I'll show you how I used all the concepts we talked about in a more practical way. So be sure to subscribe to Spinning to Full Stack's newsletter right below this article.

As always, if you have any suggestions or questions, make sure to leave a comment. You can check out my project's repository right here. Stay curious, my dudes and dudettes!