Original subtitles

In this lecture, we're going to explore what JSON Web tokens are.

We're finished with the authentication system for the application.

One word I brought up often is the word token.

What?

Our tokens.

How do they work?

These are the questions I want to answer in this lecture.

Let's start with what Web tokens are.

Tokens are encoded strings that hold your data plain and simple.

If you were to look at a token, all you would see is random gibberish.

Despite its appearance, it's one of the most effective and popular methods for authenticating a user.

They're used to transport data between the client and the server.

One of the most significant advantages of tokens is that they're digitally signed.

Let's say a hacker is able to get a hold of one.

They may be able to read the data, but they won't be able to make changes to it.

Any changes to the token will automatically invalidate it.

This mechanism limits the damages one can do if they steal a token.

In our case, tokens are assigned by Firebase.

We don't have to worry about encoding or decoding tokens.

The SDK handles most of this process.

Even if a hacker is able to grab a token, they'll have a hard time decoding the data unless they have

the signature.

On top of that, tokens expire in an hour.

This system makes it undesirable for most malicious users.

We've learned what tokens are.

Let's move on to discussing how tokens are created, tokens are generally generated on the back end.

It's not something you would create on the front end, but you can if you want to.

In the resource section of this lecture, I provide a link to the official JSON Web Tokens site.

It has every resource you'd ever want on tokens.

Web tokens aren't just for JavaScript.

You can use it with almost any programming language available.

If we were to scroll down, we'd find a playground for creating tokens.

Tokens are broken down into three sections.

The first section is the header.

This section is where we can store meta information about a token.

It's an object with two properties.

There's the algorithm and the type.

The algorithm is the formula used to encode the web token.

There's no official algorithm for Web tokens.

You can use any of the hundreds of algorithms out there.

The type is the type of token being created.

Ninety nine percent of the time this will be set to JWT for JSON Web tokens.

The next section is the payload.

This is the contents of the Web token.

It's an object filled with data.

You can store any type of data you'd like from addresses to passwords.

There's no limit as to how much data can be stored.

And it's OK in this.

Scalability is another advantage to using tokens they're encoded, which will compact them into a small

string.

This compactness allows for a lot of data to be transferred without having to worry about overloading

the request.

The last section is the signature.

The signature is used to verify the contents of the web token.

The signature is the most critical part of a token.

It's calculated with a few things.

First, the header is encoded with base64 after it is added.

This is to separate the next part of the signature, which is the payload.

The payload is also encoded with base64.

One less dot is added to the last part of the signature.

This value is the most important part, which is the secret key.

The secret key can be anything you want.

The playground allows you to modify it.

Suppose you were to change it.

The encoded token to the left changes as well as an extra measure.

You do have the option of encoding it with base sixty four.

In the end, every part is concatenated together.

The concatenated string is hashed with the algorithm you set in the header.

The result is added to the token.

We have the opportunity to play around with this.

Let's do so.

Inside the payload, we're going to add a property called admen.

We'll set it to false.

We are creating a property for determining if we have administrative permissions and this example,

I set the admin property to false to indicate I'm not an admin.

Now, let's say I'm a malicious user who's trying to become an admin.

I would have to modify the token if I'd want to do that.

From what we've learned, we know that the middle section is where the payload data is.

The playground highlights this for us by changing the text color to purple, all copy of the encoded

string that holds the payload data.

After copying it, let's head over to Base64 Decode Dawg, and provide a link to it in the resource

section of this lecture, paste the payload into the first box and decode it.

This tool will give us access to the object that was decoded, we'll find that the admin property is

still set to false.

If I want to give myself admin permissions, I'll need to change this to true.

Then I'll copy the entire object.

At the very top of the site, I'm going to switch from decode to encode all paste the object into the

first box and encode it.

We've given ourselves admin permissions.

The last step is to update the token with the modified payload, copy the payload into your clipboard,

then we'll head back to the token playground's inside the encoded string.

We're going to replace the second section with the newly encoded string.

This trick may look like it at work, but it doesn't looking below will receive an error stating that

the signature is invalid.

On the right side, you'll find that the payload was correctly decoded.

It has the admin properties set to true.

The problem is that the payload and signature don't match.

The signature is based on the payload.

We'll need to update the signature if we want this to be a valid token.

This is where the problem begins in order to create a new signature.

We'll need to know the secret.

The problem is that I don't know what the secret is.

I may know what the header algorithm and payload are, but without the secret, I will have a hard time

creating a fake signature.

Therefore, I'm unable to generate a fake token to fool the back end.

The secret is considered the most crucial part of a token.

Even if a hacker can decode everything, it can be hard to spoof a token without the secret.

This topic leads us to one final concern is it possible to steal a token?

The answer is yes.

It's not uncommon for people to sign in online at public locations.

You shouldn't do this, but it does happen in these cases.

Someone can monitor the network and steal a token.

This issue is not exclusive to tokens.

Anything that needs to be sent between the client and server can be stolen.

This includes passwords, cookies, sessions, et cetera.

So how do we prevent hackers from doing so?

The answer is quite simple.

SSL, SSL or TLC is a standard for encrypting data when it's sent between the client and server.

Installing a certificate is a job handled by backend developers.

Therefore, not much of a concern for us.

There are hosting services that offer SSL certificates along with installation.

It's vital that you have SSL enabled on your application.

You'll have to anyway because Google will penalize you for not having an SSL certificate.

It's a standard to have one nowadays.

I always recommend grabbing one.

There are premium certificates, but free certificates will do just fine.

There isn't an excuse not to use one.

I won't be going over how to install a certificate because it's beyond this course's scope.

It's more of a backend sort of thing.

We're finished with talking about tokens, they're a reliable method of transporting data between the

client and the server.

One last thing I want to show you where you can find this token firebase generates in the application

panel of the developer tools navigate to the indexed DB storage.

Under the table of values, select the firebase off, throw in the value column, Firebase will store

an object with information about the user.

The property we're interested in is the token manager property.

This property is where Firebase is storing the token for validating the user.

It's accessible to you in case you ever need it.