1
00:00:00,150 --> 00:00:04,230
In this lecture, we're going to explore what JSON Web tokens are.

2
00:00:04,560 --> 00:00:08,010
We're finished with the authentication system for the application.

3
00:00:08,310 --> 00:00:11,430
One word I've brought up often is the word token.

4
00:00:11,760 --> 00:00:12,780
What are tokens?

5
00:00:12,990 --> 00:00:13,890
How do they work?

6
00:00:14,160 --> 00:00:17,130
These are the questions I want to answer in this lecture.

7
00:00:17,400 --> 00:00:19,920
Let's start with what web tokens are.

8
00:00:20,580 --> 00:00:23,670
Tokens are encoded strings that hold your data.

9
00:00:23,910 --> 00:00:24,870
Plain and simple.

10
00:00:25,140 --> 00:00:29,130
If you are to look at a token, all you would see is random gibberish.

11
00:00:29,370 --> 00:00:35,490
Despite its appearance, it's one of the most effective and popular methods for authenticating a user.

12
00:00:35,970 --> 00:00:40,110
They're used to transport data between the client and the server.

13
00:00:40,770 --> 00:00:45,360
One of the most significant advantages of tokens is that they're digitally signed.

14
00:00:45,660 --> 00:00:48,270
Let's say a hacker is able to get hold of one.

15
00:00:48,600 --> 00:00:53,130
They may be able to read the data, but they won't be able to make changes to it.

16
00:00:53,550 --> 00:00:57,180
Any changes to their token will automatically invalidate it.

17
00:00:57,570 --> 00:01:02,010
This mechanism limits the damage, as one can do if they steal a token.

18
00:01:02,580 --> 00:01:05,790
In our case, tokens are signed by Firebase.

19
00:01:06,060 --> 00:01:09,690
We don't have to worry about encoding or decoding tokens.

20
00:01:09,990 --> 00:01:15,510
The SDK handles most of this process, even if a hacker can grab a token.

21
00:01:15,750 --> 00:01:19,800
They'll have a hard time decoding the data unless they have the signature.

22
00:01:20,130 --> 00:01:22,980
On top of that, tokens expire in an hour.

23
00:01:23,310 --> 00:01:27,330
This system makes it undesirable for most malicious users.

24
00:01:28,760 --> 00:01:30,440
We've learned what tokens are.

25
00:01:30,740 --> 00:01:33,950
Let's move on to discussing how tokens are created.

26
00:01:34,490 --> 00:01:37,370
Tokens are generally generated on the back end.

27
00:01:37,910 --> 00:01:42,060
It's not something you would create on the front end, but you can if you want to.

28
00:01:42,320 --> 00:01:49,100
In the resource section of this lecture, I provide a link to the official JSON web token site.

29
00:01:49,370 --> 00:01:56,480
It has every resource you'd ever want on tokens where tokens aren't just for JavaScript, you can use

30
00:01:56,480 --> 00:01:59,270
it with almost any programming language available.

31
00:01:59,780 --> 00:02:04,010
If we were to scroll down, we'd find a playground for creating tokens.

32
00:02:04,250 --> 00:02:06,860
Tokens are broken down into three sections.

33
00:02:07,130 --> 00:02:09,289
The first section is the header.

34
00:02:09,710 --> 00:02:13,460
This section is where we can store meta information about a token.

35
00:02:13,820 --> 00:02:16,010
It's an object with two properties.

36
00:02:16,280 --> 00:02:18,380
There's the algorithm and the type.

37
00:02:18,830 --> 00:02:22,820
The algorithm is the formula used to encode the web token.

38
00:02:23,150 --> 00:02:25,880
There's no official algorithm for web tokens.

39
00:02:26,120 --> 00:02:29,360
You can use any of the hundreds of algorithms out there.

40
00:02:29,750 --> 00:02:32,850
The type is the type of token being created.

41
00:02:33,170 --> 00:02:35,060
99 percent of the time.

42
00:02:35,090 --> 00:02:39,350
This will be set to JWT for JSON web tokens.

43
00:02:39,950 --> 00:02:42,140
The next section is the payload.

44
00:02:42,410 --> 00:02:44,540
This is the contents of the web token.

45
00:02:44,780 --> 00:02:46,730
It's an object filled with data.

46
00:02:47,030 --> 00:02:49,550
You can store any type of data you'd like.

47
00:02:49,790 --> 00:02:55,790
From addresses to passwords, there's no limit as to how much data can be stored in a token.

48
00:02:56,060 --> 00:03:00,020
This scalability is another advantage to using tokens.

49
00:03:00,290 --> 00:03:03,920
They are encoded, which will compact them into a small string.

50
00:03:04,310 --> 00:03:10,610
This compactness allows for a lot of data to be transferred without having to worry about overloading

51
00:03:10,610 --> 00:03:11,480
the request.

52
00:03:12,110 --> 00:03:14,600
The last section is the signature.

53
00:03:14,990 --> 00:03:18,950
The signature is used to verify the contents of the web token.

54
00:03:19,340 --> 00:03:22,460
The signature is the most critical part of a token.

55
00:03:22,850 --> 00:03:24,950
It's calculated with a few things.

56
00:03:25,220 --> 00:03:28,610
First, the header is encoded with base 64.

57
00:03:29,000 --> 00:03:31,010
After it, a dot is added.

58
00:03:31,310 --> 00:03:35,600
This is to separate the next part of the signature, which is the payload.

59
00:03:35,960 --> 00:03:39,050
The payload is also encoded with base64.

60
00:03:39,560 --> 00:03:43,220
One last dot is added to the last part of the signature.

61
00:03:43,490 --> 00:03:47,510
This value is the most important part, which is the secret key.

62
00:03:47,870 --> 00:03:50,300
The secret key can be anything you want.

63
00:03:50,600 --> 00:03:52,940
The playground allows you to modify it.

64
00:03:53,180 --> 00:03:59,760
Suppose you were to change it, the encoded token to the left changes, as well as an extra measure.

65
00:03:59,780 --> 00:04:03,290
You do have the option of encoding it with base64.

66
00:04:03,890 --> 00:04:07,070
In the end, every part is concatenated together.

67
00:04:07,370 --> 00:04:12,080
The concatenated string is hashed with the algorithm you set in the header.

68
00:04:12,410 --> 00:04:14,540
The result is added to the token.

69
00:04:15,110 --> 00:04:17,779
We have the opportunity to play around with this.

70
00:04:17,990 --> 00:04:20,570
Let's do so inside the payload.

71
00:04:20,690 --> 00:04:25,160
We're going to add a property called admin will set it to false.

72
00:04:27,660 --> 00:04:32,220
We're creating a property to determine if we have administrative permissions.

73
00:04:32,460 --> 00:04:38,520
In this example, I set the admin property to false to indicate I'm not an admin.

74
00:04:39,000 --> 00:04:42,930
Now let's say I'm a malicious user who's trying to become an admin.

75
00:04:43,320 --> 00:04:46,710
I would have to modify the token if I wanted to do that.

76
00:04:47,340 --> 00:04:52,950
From what we've learned, we know that the middle section is where the payload data is.

77
00:04:53,310 --> 00:04:59,580
The playground highlights this for us by changing the text color to purple, all copy of the encoded

78
00:04:59,580 --> 00:05:01,830
string that holds the payload data.

79
00:05:04,390 --> 00:05:09,190
After copying it, let's head over to base 64 Rd Code.org.

80
00:05:09,520 --> 00:05:13,180
I'll provide a link to it in the resource section of this lecture.

81
00:05:13,600 --> 00:05:17,260
Paste the payload into the first box and decode it.

82
00:05:19,860 --> 00:05:26,700
This tool will give us access to the object that was encoded will find that the admin property is still

83
00:05:26,700 --> 00:05:27,750
set to false.

84
00:05:28,080 --> 00:05:33,660
If I want to give myself admin permissions, I'll need to change this property to true.

85
00:05:36,470 --> 00:05:39,110
Then I'll copy the entire object.

86
00:05:41,540 --> 00:05:46,700
At the very top of the sites, I'm going to switch from decode to encode.

87
00:05:47,180 --> 00:05:50,630
I'll paste the object into the first box and encode it.

88
00:05:53,310 --> 00:05:55,740
We've given ourselves admin permissions.

89
00:05:56,040 --> 00:06:00,360
The last step is to update the token with the modified payload.

90
00:06:00,720 --> 00:06:08,460
Copy the payload into your clipboard, then will head back to the token playgrounds inside the encoded

91
00:06:08,460 --> 00:06:09,030
string.

92
00:06:09,210 --> 00:06:13,590
We're going to replace the second section with the newly encoded string.

93
00:06:16,210 --> 00:06:19,090
This trick may look like it'll work, but it doesn't.

94
00:06:19,390 --> 00:06:23,980
Looking below will receive an error stating that the signature is invalid.

95
00:06:24,310 --> 00:06:28,780
On the right side, you'll find that the payload was correctly decoded.

96
00:06:29,170 --> 00:06:31,930
It has the admin property set to true.

97
00:06:32,350 --> 00:06:35,770
The problem is that the payload and signature don't match.

98
00:06:36,100 --> 00:06:38,320
The signature is based on the payload.

99
00:06:38,590 --> 00:06:42,820
We'll need to update the signature if we want this to be a valid token.

100
00:06:43,480 --> 00:06:45,460
This is where the problem begins.

101
00:06:45,670 --> 00:06:49,750
In order to create a new signature, we'll need to know the secrets.

102
00:06:50,110 --> 00:06:53,020
The problem is that I don't know what the secret is.

103
00:06:53,320 --> 00:06:59,920
I may know what the header algorithm and payload are, but without the secret, I will have a hard time

104
00:06:59,920 --> 00:07:01,480
creating a fake signature.

105
00:07:01,840 --> 00:07:05,980
Therefore, I'm unable to generate a fake token to fool the back end.

106
00:07:06,550 --> 00:07:12,670
The secret is considered the most crucial part of a token, even if a hacker can decode everything.

107
00:07:12,850 --> 00:07:15,730
It can be hard to spoof a token without the secret.

108
00:07:18,260 --> 00:07:23,330
This topic leads us to one final concern is it possible to steal a token?

109
00:07:23,600 --> 00:07:24,740
The answer is yes.

110
00:07:25,010 --> 00:07:29,390
It's not uncommon for people to sign in online at public locations.

111
00:07:29,660 --> 00:07:33,350
You shouldn't do this, but it does happen in these cases.

112
00:07:33,500 --> 00:07:36,410
Someone can monitor the network and steal a token.

113
00:07:37,010 --> 00:07:39,800
This issue is not exclusive to tokens.

114
00:07:40,070 --> 00:07:44,390
Anything that needs to be sent between the client and server can be stolen.

115
00:07:44,690 --> 00:07:48,500
This includes passwords, cookies, sessions, et cetera.

116
00:07:48,800 --> 00:07:51,710
So how do we prevent hackers from doing so?

117
00:07:52,280 --> 00:07:53,870
The answer is quite simple.

118
00:07:54,020 --> 00:08:01,400
SSL, SSL or TLC is a standard for encrypting data when it's sent between the client and server.

119
00:08:01,800 --> 00:08:08,300
Installing a certificate is a job handled by backend developers, therefore not much of a concern for

120
00:08:08,300 --> 00:08:08,630
us.

121
00:08:09,020 --> 00:08:14,210
There are hosting services that offer SSL certificates along with installation.

122
00:08:14,570 --> 00:08:18,440
It's vital that you have SSL enabled on your application.

123
00:08:19,070 --> 00:08:24,230
You'll have to do anyway, because Google will penalize you for not having an SSL certificate.

124
00:08:24,620 --> 00:08:26,750
It's a standard to have one nowadays.

125
00:08:26,990 --> 00:08:28,760
I always recommend grabbing one.

126
00:08:29,150 --> 00:08:33,740
There are premium certificates, but free certificates will do just fine.

127
00:08:34,070 --> 00:08:36,289
There isn't an excuse not to use one.

128
00:08:36,559 --> 00:08:42,049
I won't be going over how to install a certificate because it's beyond this course's scope.

129
00:08:42,380 --> 00:08:44,240
It's more of a back end sort of thing.

130
00:08:46,740 --> 00:08:53,310
We're finished talking about tokens, they're a reliable method of transporting data between the client

131
00:08:53,310 --> 00:08:54,150
and the server.

132
00:08:54,510 --> 00:09:01,230
One last thing I want to show you where you can find the token Firebase generates in the application

133
00:09:01,230 --> 00:09:03,060
panel of the developer tools.

134
00:09:03,240 --> 00:09:08,620
Navigate to the indexed DB storage under the table of values.

135
00:09:08,640 --> 00:09:15,810
Select the Firebase Auth Rule in the value column, Firebase will store an object with information about

136
00:09:15,810 --> 00:09:16,440
the user.

137
00:09:16,740 --> 00:09:21,000
The property we're interested in is the STS token manager.

138
00:09:21,000 --> 00:09:21,720
Your property.

139
00:09:22,110 --> 00:09:26,850
This property is where Firebase is storing the token for validating the user.

140
00:09:27,180 --> 00:09:30,120
It's accessible to you in case you ever need it.