Let’s talk about JWT

Do you know what JSON Web Tokens are, or do you know how JSON Web Tokens work?

While I give you a moment to consider those two questions, let me introduce myself.

Hi, I'm Jess Temporal a senior developer advocate at Auth0.

If you've never heard of Auth0 before we are an identity platform, which means we try to make it as easy as possible for anybody to implement authentication.

So you can focus on building your products.

I'm also an instructor at LinkedIn Learning.

And Data Bootcamp, a bootcamp about data science here in Brazil, and I have a podcast about data science called Pizza de Dados that discusses data science in a fun way in Portuguese.

So if you want to learn a little bit about data science and want to practice some Portugese, you are more than welcome to hear some of our episodes.

Also, you can find me on the internet by the handle @jesstemporal, but enough about me, let's go back to the issue at hand.

What JWTs, and how they work.

And it is impossible to talk about 'jots' and yes, you can call it JWT or 'jot without mentioning the amazing effort that was made to create a collection of specifications and standards that are part of the JOSE is specifically.

One specification that is five of the JOSE initiative is the RFC 7519, that outlines what a JWT is.

So imagine this, you need to create a format that can be used in a space constraining environment to carry information from one point to another.

Like for example, HTTP requests.

That's where the Requests for Comment 7519 comes in, it outlines what a jot is and how it is structured.

And this RFC is also commonly known as the 'Jots specification'.

And that's going to be our focused today.

So a jot usually is a standardized string that represents information in a compact way.

Let's break this down a little bit further.

The information we want to carry is structured as a JSON object, we'll see more about this in a little bit.

The web part refers to the constrained environment that we have.

Which usually is the requests that web applications and APIs and online systems exchange in between front end and back end for example.

Finally, we have the token and as a friend of mine likes to say, our token is an unique identifier representing something.

So it conveys some meaning.

And here it is, what a jot looks like.

If you never see one, nice to meet your jot.

If you look closely, this gigantic string have a structure consisting of three parts.

Are header, a payload, and a signature.

The header contains information about the token itself.

For example, what type of token it is and what algorithm was used for signing that token.

So if you take this JSON object, and encoded into a base 64 string, we get the first part of our token.

The payload contains information about a resource.

In our login scenario, for example, this would be information about end-user.

Like the example we have here.

This is also base-64 encoded like the header.

And before we talk about the signature, that is a little bit different from these first two parts.

We need to talk about claims.

Each line, each key/value pair in a payload, or in the header represents a claim.

And there are three types of claims.

The first one, are reserved claims, and these claims comes from the jot specification.

That is subject, that is usually the user ID, that is issuer-that is who issued the token.

And one important thing about this is that there is an expire date, for example.

And one of the steps for validating tokens is checking if a token is expired or not.

There are also the second type of claims and those are the public claims.

They aren't defined in the jot specification, but they are standardized in a way by IANA, which is one of the organizations on the internet.

And the idea is that everybody would follow the same naming conventions for the claims.

So that, for example, given name is that the first same, family name instead of last name and so on.

That way everybody could know what each information means and how to retrieve them.

And the last type of claims is the private ones.

And there is supposed to be anything that you want, anything that you find useful and that you need for your systems to work.

As long as you keep it a valid JSON, you can put anything you want in here.

I mean, anything really [laughs].

Also keep in mind that the more information you have on the JSON in the payload, the bigger the string that you have to pass along, on each request.

So try to keep it as small and only the necessary information.

Also, as you may have noticed the information, the payload is only encoded.

So don't put sensitive data in the payload, because anyone can decode it and could get ahold of that data.

Now, you know what theheader and the payloads about let's talk about the signature.

It's time to see what the signature looks like.

And if you remember what I said before, the signature is a little bit different from the first two parts we just saw, especially because it is a way for us to verify that the token wasn't tempered with.

That means that nobody tried to change anything in the token while in transit, for example.

Because the signature is based off the header and the payload, and depending on the algorithm, a secret or key.

In your life, your secret will be something more secure like this random string, for example, instead of the first example that we had there.

And one important thing is that there are two types of algorithms that can be used for signing tokens.

The first type, like the one we just saw here, are the symmetrical algorithms and it needs a secret key for signing and validating token.

The second type is called asymmetrical algorithms and, and an asymmetrical alogorithm, like AES-256, for example, use a private key for signing and a public key for verifying the token.

This way, you can keep your private key secure and share the public key, so the other side can verify your tokens.

And guess what?

The JOSE specification actually defines a format for sharing public keys, that is known as the JSON Web Key.

JSON Web Keys, like JSON Web Tokens have one RFC that you can check.

And that is the RFC 7517.

And if you are following the OpenID connect, you have a well-known endpoint that will make this public key available.

And in case you haven't seen a JWK before, this is what it looks like.

Now let's create a token together.

And the first thing we are going to do is take the header, with the token information and encode it into a base-64 string that would look like something like this.

Now we can take the payload data and also encode it into a base-64 string, and this is what it would look like.

And finally, we can create the signature by taking the payload we just created and the header and pass it along to the hmac SHA 256 algorithm, together with the secret and we can get our signature.

Now, if you get all of these pieces together, by concatenating them with periods, we can see our Web Token.

And if I copied this token and paste it on JWT.io, You can check the contents of the token.

You would have with the example of token that comes with a website,now, if your base ours, you can see here, the details.

If you scroll down a little bit further, you can see that the signature was verified by JWT.io JWT.io was created by us at Auth0 to help you to quickly check JWTs.

And one good thing is that it doesn't store tokens your place here.

So it can be safely used for debugging.

So now that you've seen all about JSON Web Tokens, you may be wondering where can you see it in action?

And the good thing is JSON Web Tokens can be used for different things.

And if you're thinking of interacting with APIs, you may have heard of access tokens before.

And the good thing is, is that an access token is going to contain data in the payload that is relevant to the API.

Like an audience and scopes, for example.

Now keep in mind that an access token doesn't have to be a JWT, but there is a new RFC, authored by Vittorio Bertocci,Auth0's principle architect that came out in October 2021, that outlines how to use JWTs as access tokens.

I recommend you read that for understanding what a JWT as an access token should look like and understanding, for example, what claims and verification steps are required.

Another way that you were going to see a JWT in the wild is being used as an ID token.

And that's because ID tokens contain all relevant data about a user after the user is authenticated.

So in that way, the front end can explain information about the user, for example, the user name, their profile picture, and so.

And it's important to notice that as defined by the openID connect, ID tokens are always JWTs.

Now, since we are talking about tokens, you may have heard of refresh tokens, but it is important to know as well that usually refresh tokens aren't JWTs and that's why I'm not talking about it here in more detail.

Now that you've seen how JWTs are made, you may be wondering what should you do to be safer when using JWTs on your own applications?

And the first thing you should avoid is to store your JWTs in local storage.

If needed, you should store them in memory, and this will help you avoid XSS attacks.

Also most times we don't verify JWTs in the front end, your front end should delegate the verification step to the backend.

But one thing you can do in the front end without verifying the token is checking the expiry dates that comes in the payload.

And then you can already reject that token if the token is expired.

Finally, remember not to put sensitive data in the payload of the token because the payload is only base 64 encoded, and anyone could decode the data and grab it and use it in suspicious ways.

I've showed you JWT.io before, when we were validating the token we just created.

And other than validating tokens, you can check out a very comprehensive list of libraries for dealing wth JWTs.

These will help you properly handled JWTs on your applications and have fun with it.

Also Auth0 has a free book with detailed information on JWTs.

More examples than you've seen today and a good list of best practices.

Finally, so you can get all of these links, these slides were made available, under the slides.com/jtemporal/jwt.

And if you have any questions, you can find me on most social media under the handle 'jesstemporal'.

And thank you very much for your time.

And I'll see you soon.