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've brought up often is the word token.
What are 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 are 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 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 their token will automatically invalidate it.
This mechanism limits the damage, as one can do if they steal a token.
In our case, tokens are signed by Firebase.
We don't have to worry about encoding or decoding tokens.
The SDK handles most of this process, even if a hacker can 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 token site.
It has every resource you'd ever want on tokens where 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.
99 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 in a token.
This scalability is another advantage to using tokens.
They are 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 base 64.
After it, a dot is added.
This is to separate the next part of the signature, which is the payload.
The payload is also encoded with base64.
One last 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 base64.
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 admin will set it to false.
We're creating a property to determine if we have administrative permissions.
In 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 wanted 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 base 64 Rd Code.org.
I'll 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 encoded will find that the admin property is still
set to false.
If I want to give myself admin permissions, I'll need to change this property to true.
Then I'll copy the entire object.
At the very top of the sites, I'm going to switch from decode to encode.
I'll 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 will head back to the token playgrounds inside the encoded
string.
We're going to replace the second section with the newly encoded string.
This trick may look like it'll 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 property 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 secrets.
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 do 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 back end sort of thing.
We're finished 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 the 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 Auth Rule in the value column, Firebase will store an object with information about
the user.
The property we're interested in is the STS token manager.
Your 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.