1
00:00:00,000 --> 00:00:04,869
[MUSIC]

2
00:00:04,869 --> 00:00:06,266
In the previous lessons,

3
00:00:06,266 --> 00:00:10,110
we have seen several different
kinds of authentication schemes.

4
00:00:10,110 --> 00:00:14,910
We started with basic authentication, then
we looked at how we can use cookies for

5
00:00:14,910 --> 00:00:18,290
doing authentication, and
even signed cookies, and

6
00:00:18,290 --> 00:00:22,090
thereafter, we looked at
session-based authentication.

7
00:00:22,090 --> 00:00:27,070
Where the server is keeping track of
information about each client, and

8
00:00:27,070 --> 00:00:30,680
then the cookie will be used as a way
of indexing into the server-side

9
00:00:30,680 --> 00:00:35,720
database to extract additional
information, to validate the user.

10
00:00:35,720 --> 00:00:41,160
Now, the cookie and session-based
authentications are not scalable,

11
00:00:41,160 --> 00:00:47,300
because there server needs to keep
track of all the different users.

12
00:00:48,820 --> 00:00:53,120
Even though, this is done outside
the HTTP protocol itself, but

13
00:00:53,120 --> 00:00:56,160
still the fact that you need to keep track

14
00:00:56,160 --> 00:01:00,660
of all the section information of the
server site, makes it not very scalable.

15
00:01:00,660 --> 00:01:04,510
So this is where token-based
authentication has

16
00:01:04,510 --> 00:01:06,570
proved to be very useful.

17
00:01:06,570 --> 00:01:11,260
we'll look at token-base authentication
a little more detailed in this lecture and

18
00:01:11,260 --> 00:01:12,830
exercise that follows.

19
00:01:14,680 --> 00:01:18,880
Again, quickly reviewing cookies and
session based authentication.

20
00:01:18,880 --> 00:01:20,580
With cookie based authentication,

21
00:01:20,580 --> 00:01:25,240
we notice that cookies are stored on the
client side, and the cookies are included

22
00:01:25,240 --> 00:01:29,510
in every outgoing request message whereby,
the server is reminded about

23
00:01:29,510 --> 00:01:35,050
that specific client,
by extracting information from the cookie.

24
00:01:35,050 --> 00:01:40,550
Cookie can be used together with sessions,
whereby the cookies store the session ID,

25
00:01:40,550 --> 00:01:44,650
and then when the server receives
the incoming request from the cookie,

26
00:01:44,650 --> 00:01:49,770
it extracts the session ID and uses that
as an index into the server-side session

27
00:01:49,770 --> 00:01:55,210
store to retrieve the session
information for the particular client.

28
00:01:55,210 --> 00:01:56,840
Now, this approach as I said,

29
00:01:56,840 --> 00:02:01,234
is not very scalable because if you have
thousands of sessions, the server needs to

30
00:02:01,234 --> 00:02:04,980
keep track of all these thousands
of sessions on the server side.

31
00:02:04,980 --> 00:02:10,820
Even though it is done
independent of HTTP in a store,

32
00:02:10,820 --> 00:02:13,770
either a file store or a database.

33
00:02:13,770 --> 00:02:14,610
But still,

34
00:02:14,610 --> 00:02:19,520
the fact that you need to track all of
these information makes it not scalable.

35
00:02:19,520 --> 00:02:23,960
So, again, to remind you one more time,

36
00:02:23,960 --> 00:02:27,201
why do we talk about
token-based authentication?

37
00:02:27,201 --> 00:02:32,260
Session-based authentication, as we have
seen earlier, works perfectly fine for

38
00:02:32,260 --> 00:02:39,910
web applications and can easily
take care of user authentication.

39
00:02:39,910 --> 00:02:43,660
But then, session-based authentication,
while it's the principle of

40
00:02:43,660 --> 00:02:48,280
stateless servers and
also leads to scalability problems.

41
00:02:48,280 --> 00:02:52,727
The second issue is,
mobile applications do not

42
00:02:52,727 --> 00:02:58,090
handled session-based
authentications very well.

43
00:02:58,090 --> 00:03:01,742
Similarly, mobile applications have
a hard time dealing with cookies.

44
00:03:01,742 --> 00:03:08,048
So, in such circumstances where
your server is serving data for

45
00:03:08,048 --> 00:03:13,610
both a web application,
as well as a mobile app.

46
00:03:13,610 --> 00:03:19,275
Then, the session based authentication
will not be very useful, and

47
00:03:19,275 --> 00:03:25,139
this is where token based authentication
becomes a lot more easy to use.

48
00:03:25,139 --> 00:03:29,369
In a token-based authentication
as the name in place,

49
00:03:29,369 --> 00:03:34,589
the server will issue a token to
a validated user, and all subsequent

50
00:03:34,589 --> 00:03:40,803
requests coming from the client side,
will bear the token in the request itself.

51
00:03:40,803 --> 00:03:48,992
Either in the form of a request header or
in the body of the request message.

52
00:03:48,992 --> 00:03:53,410
Furthermore, token-based
authentication also helps us to

53
00:03:53,410 --> 00:03:57,965
deal with what are called CORS or
CSRF problems.

54
00:03:57,965 --> 00:04:00,480
Cross-origin resource sharing problems and
so

55
00:04:00,480 --> 00:04:04,360
on, I'll briefly talk about
cost in the next module.

56
00:04:04,360 --> 00:04:07,540
But for the moment, token-based
authentication addresses some of

57
00:04:07,540 --> 00:04:13,430
the issues that lies with cars and
cross-site request forgery related issues.

58
00:04:13,430 --> 00:04:17,680
Not only that, token-based
authentication is a lot more easy for

59
00:04:17,680 --> 00:04:21,700
one application to share its
authentication with another application.

60
00:04:21,700 --> 00:04:24,610
Of course,
this is all done in a secure manner.

61
00:04:24,610 --> 00:04:28,867
But, with session based authentication,
that is not straight forward.

62
00:04:28,867 --> 00:04:32,272
How does token-based authentication work?

63
00:04:32,272 --> 00:04:34,260
In token-based authentication,

64
00:04:34,260 --> 00:04:40,020
the user first needs to validate
himself or herself on the server side.

65
00:04:40,020 --> 00:04:44,040
Now, this validation could take on
the forms that we have seen earlier.

66
00:04:44,040 --> 00:04:48,519
So we can use a local validation
using username and password.

67
00:04:48,519 --> 00:04:53,111
Or, we can even use third
party validation using

68
00:04:53,111 --> 00:04:58,267
technologies like, oauth or
oauth 2.0 or open ID.

69
00:04:58,267 --> 00:05:03,700
We'll talk briefly about oauth and
oauth 2.0 in the next module.

70
00:05:03,700 --> 00:05:08,790
But, no matter which way the user
authenticates, once the user

71
00:05:08,790 --> 00:05:14,370
is authenticated, right after, your server
can simply issue a token to the user.

72
00:05:14,370 --> 00:05:18,790
And all subsequent communication
between the user and

73
00:05:18,790 --> 00:05:23,658
the server,
can be done simply using this token.

74
00:05:23,658 --> 00:05:29,240
JSON Web Token that we will talk about,
is one such token-based authentication

75
00:05:29,240 --> 00:05:35,465
scheme, and there server when it creates
this token, it will create a signed token.

76
00:05:35,465 --> 00:05:40,315
Using a secret on the server site
which only the server knows.

77
00:05:40,315 --> 00:05:43,965
So thereby, even if a third
party in towards and between and

78
00:05:43,965 --> 00:05:49,185
tries to manipulate the token,
even if it captures the token and

79
00:05:49,185 --> 00:05:53,045
tries to manipulate the token,
the token will become invalid.

80
00:05:53,045 --> 00:05:57,201
And so, that way of protecting the user is

81
00:05:57,201 --> 00:06:02,250
easily feasible, all subsequent requests

82
00:06:02,250 --> 00:06:07,430
from the client side should
carry the token in the request,

83
00:06:07,430 --> 00:06:11,870
either, as I said, in the header or
in the body of the request message.

84
00:06:11,870 --> 00:06:16,120
So when the server receives this token,
the server will verify the token,

85
00:06:16,120 --> 00:06:20,810
to ensure that this is a valid token,
and then if it is a valid token,

86
00:06:20,810 --> 00:06:25,430
the server will then respond
to the incoming request.

87
00:06:25,430 --> 00:06:31,210
As I mentioned, JSON Web Tokens is one
such token-based authentication scheme.

88
00:06:31,210 --> 00:06:35,838
JSON Web Token,
is a very simple way of encoding

89
00:06:35,838 --> 00:06:41,174
information in a token then
pass it to the client site.

90
00:06:41,174 --> 00:06:45,702
JSON Web Token itself
is based on standards,

91
00:06:45,702 --> 00:06:49,670
this is based on the IETF RFC 7519.

92
00:06:49,670 --> 00:06:53,499
IETF here, stands for
the Internet Engineering Task Force.

93
00:06:53,499 --> 00:07:00,011
The organization that mandates
everything about how the internet works,

94
00:07:00,011 --> 00:07:06,427
and deals with the protocols and
the policies, related to the internet.

95
00:07:06,427 --> 00:07:10,391
The RFC, stands for
the standards document,

96
00:07:10,391 --> 00:07:15,270
in IETF terms, RFC stands for
Request for Comments.

97
00:07:15,270 --> 00:07:18,650
And each such standards
document carries a number.

98
00:07:18,650 --> 00:07:23,560
7519 in this case refers to the document,

99
00:07:23,560 --> 00:07:27,250
the standard document
related to JSON Web Token.

100
00:07:27,250 --> 00:07:31,420
The JSON Web Token itself is a self
contained token, it carries all

101
00:07:31,420 --> 00:07:37,250
the information within itself,
that is necessary to identify the user.

102
00:07:37,250 --> 00:07:43,080
Not only that, a JSON Web Token can
be shared between two applications.

103
00:07:43,080 --> 00:07:46,930
So for example, one application when
it authenticates and then gets hold of

104
00:07:46,930 --> 00:07:51,760
a JSON Web Token, can pass that
JSON Web Token to and in that application,

105
00:07:51,760 --> 00:07:56,950
that it is willing to authorize to
access the server on its behalf.

106
00:07:56,950 --> 00:08:00,200
This sharing of the token is
done in a very secure manner,

107
00:08:00,200 --> 00:08:03,460
so don't worry too much
about security in there.

108
00:08:03,460 --> 00:08:04,990
This is not in a secure manner,

109
00:08:04,990 --> 00:08:09,090
where by the sharing of the token
between one application to another.

110
00:08:09,090 --> 00:08:13,250
Thereby, the authorization is transferred
over to a second application, and

111
00:08:13,250 --> 00:08:17,740
the second application can authorize
on behalf of the first application,

112
00:08:17,740 --> 00:08:18,990
to communicate with the server.

113
00:08:20,200 --> 00:08:24,200
This is feasible with tokens.

114
00:08:24,200 --> 00:08:28,710
Now of course, the engineer in you will
obviously be wondering what exactly is

115
00:08:28,710 --> 00:08:32,690
inside a JSON Web Token,
and how is it useful?

116
00:08:32,690 --> 00:08:39,120
A JSON Web Token, as I said,
is encoded into a long string and

117
00:08:39,120 --> 00:08:43,530
this string itself can be interpreted
as consisting of three parts.

118
00:08:43,530 --> 00:08:49,470
The string itself can, or the encoded
string itself contains three parts,

119
00:08:49,470 --> 00:08:52,896
the Header, the Payload,
and the Signature.

120
00:08:52,896 --> 00:08:59,070
That carries enough information
about how this token is encoded.

121
00:08:59,070 --> 00:09:03,780
The Header itself contains the specific
algorithm that is used for

122
00:09:03,780 --> 00:09:08,460
encoding this JSON Web Token,
and the type of the token itself.

123
00:09:08,460 --> 00:09:16,280
The algorithm in this case, would be
HS256 which is a 256 bit encoding scheme,

124
00:09:16,280 --> 00:09:21,140
that is used for hashing
the information inside of the token.

125
00:09:21,140 --> 00:09:24,350
And in this case, this happens
to be the JSON Web Token, and so

126
00:09:24,350 --> 00:09:27,870
the type field will be set to JWT.

127
00:09:27,870 --> 00:09:33,210
And so that is the information that is
stored in the header of JSON Web Token.

128
00:09:33,210 --> 00:09:38,800
The Payload itself, carries information
that helps you to identify the user.

129
00:09:38,800 --> 00:09:41,440
In the exercise that we will do,

130
00:09:41,440 --> 00:09:46,730
the hour payload only carry the ID
of the user inside the payload.

131
00:09:46,730 --> 00:09:48,720
No other information is necessary.

132
00:09:48,720 --> 00:09:51,690
This ID can be used on the server side,

133
00:09:51,690 --> 00:09:58,350
to index into the Mongo DB to retrieve
the full user information if required.

134
00:09:58,350 --> 00:10:02,050
So, you will see that
we'll encoding the ID and

135
00:10:02,050 --> 00:10:05,020
then storing it in
the payload of that message.

136
00:10:05,020 --> 00:10:09,470
You can store additional information in
the payload of the message if you require.

137
00:10:09,470 --> 00:10:11,410
But the more information
that you stored there,

138
00:10:11,410 --> 00:10:15,720
the larger the corresponding
JSON Web Token is going to me.

139
00:10:15,720 --> 00:10:20,010
So, try to limit the amount of information
that you stored in the payload

140
00:10:20,010 --> 00:10:22,155
of the JSON Web Token.

141
00:10:22,155 --> 00:10:27,545
As we will see in the exercise,
we have a node module that enables us

142
00:10:27,545 --> 00:10:30,875
to encode and create a JSON Web Token,

143
00:10:30,875 --> 00:10:34,395
based on the information that
we want to put in the payload.

144
00:10:34,395 --> 00:10:38,735
Now, when you create a JSON Web Token,
you also supply a signature.

145
00:10:38,735 --> 00:10:44,929
A secret key on the server side which is
used for encoding this JSON Web Token,

146
00:10:44,929 --> 00:10:51,044
and that secret is also included in
the signature part of the JSON Web Token.

147
00:10:51,044 --> 00:10:55,232
The signature itself is included
in such a way that there

148
00:10:55,232 --> 00:10:58,797
is a basics before encoded header and
payload,

149
00:10:58,797 --> 00:11:04,750
which is then encoded using the specific
secret that is used by the server.

150
00:11:04,750 --> 00:11:08,644
And this encoded in, as I said the HMAC,

151
00:11:08,644 --> 00:11:14,144
that we have referred to in one
of the previous lessons and

152
00:11:14,144 --> 00:11:20,922
using the 256 bit hashing, and
that is included in the signature.

153
00:11:20,922 --> 00:11:25,118
So, when this JSON Web Token is
received on the server side, and

154
00:11:25,118 --> 00:11:30,094
when the server decodes this token,
then the server is able to cross check to

155
00:11:30,094 --> 00:11:34,525
make sure that this JSON Web Token
has not been tampered by anybody,

156
00:11:34,525 --> 00:11:39,460
while the token is being passed between
the client and the server site.

157
00:11:39,460 --> 00:11:43,020
So if you know anything about security,
and intruders,

158
00:11:43,020 --> 00:11:47,670
and so on, you understand why it is
important to encode the token, and

159
00:11:47,670 --> 00:11:53,250
verify the authenticity of
the token on the server site.

160
00:11:53,250 --> 00:11:58,640
As I mentioned, if you need to deal with
JSON Web Tokens in your node application.

161
00:11:58,640 --> 00:12:02,810
There is a specific node module called
as the jsonwebtoken Node Module.

162
00:12:02,810 --> 00:12:07,830
This node module implements
the JSON Web Token related standards, and

163
00:12:07,830 --> 00:12:10,640
it can be included into
your node application.

164
00:12:10,640 --> 00:12:15,190
This module itself, provides a method
called sign which allows you to sign and

165
00:12:15,190 --> 00:12:18,910
issue the token to the client
from the server side.

166
00:12:18,910 --> 00:12:21,820
It also contains a verify method.

167
00:12:21,820 --> 00:12:27,040
Which can be used to
verify the authenticity or

168
00:12:27,040 --> 00:12:33,380
to ensure the authenticity of
the incoming JSON Web token,

169
00:12:33,380 --> 00:12:38,620
so we will be making use of the JSON Web
token module, in our exercise.

170
00:12:38,620 --> 00:12:42,010
Together with the JSON Web Token module,

171
00:12:42,010 --> 00:12:47,450
we also used the Passport-JWT module,
node module.

172
00:12:47,450 --> 00:12:54,547
Which provides the jwt based strategies
for our passport authentication module.

173
00:12:54,547 --> 00:12:59,441
So this provides a passport strategy for
authenticating using JSON Web Token.

174
00:12:59,441 --> 00:13:06,153
So this allows you to authenticate RESTful
endpoint using the JWT as the method for

175
00:13:06,153 --> 00:13:12,240
dong the validation, without
requiring the server to use sessions.

176
00:13:12,240 --> 00:13:17,300
Now, the JWT passport module,

177
00:13:17,300 --> 00:13:21,710
supports a method of even
extracting the JWT token from

178
00:13:21,710 --> 00:13:26,970
the incoming request message, and then
even verifying the token on your behalf.

179
00:13:26,970 --> 00:13:31,470
The Passport-JWT module intern,
uses the JSON Web Token module for

180
00:13:31,470 --> 00:13:34,550
doing the verification
of that JSON Web Token.

181
00:13:34,550 --> 00:13:40,300
The token itself can be carried in
the header of the incoming request,

182
00:13:40,300 --> 00:13:44,350
in the header, even in the authentication
header of the incoming request,

183
00:13:44,350 --> 00:13:46,940
which is what we will be
doing in the exercise.

184
00:13:46,940 --> 00:13:51,420
The token can be also carried in the body
of the incoming request, in which case,

185
00:13:51,420 --> 00:13:54,610
we have to extract the token from
the body of the incoming request and

186
00:13:54,610 --> 00:13:56,352
then make use of it.

187
00:13:56,352 --> 00:14:01,170
The Passport-JWT module,
supports that also if you choose to

188
00:14:01,170 --> 00:14:06,580
use that as way of passing the token
back from the client to the server site.

189
00:14:06,580 --> 00:14:11,600
The JSON Web Token, can be also included
in the URL query parameters if you so

190
00:14:11,600 --> 00:14:16,440
choose to, and can be extracted
from there b Passport-JWT and

191
00:14:16,440 --> 00:14:18,370
used for authentication.

192
00:14:18,370 --> 00:14:22,783
Now, with this quick understanding
of JSON Web Tokens and

193
00:14:22,783 --> 00:14:27,915
how they are useful, we will move on
to the exercise where we will use

194
00:14:27,915 --> 00:14:33,230
the Passport-JWT module,
together with the JSON Web Token module,

195
00:14:33,230 --> 00:14:38,211
and configure our Express Rest API
server to use JSON Web Tokens.

196
00:14:38,211 --> 00:14:41,589
[MUSIC]