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

2
00:00:04,470 --> 00:00:10,326
The Express REST API server that
we implemented in the previous

3
00:00:10,326 --> 00:00:17,750
module allows any user to perform any of
the GET or POST or DELETE operations.

4
00:00:17,750 --> 00:00:21,360
There is no control on who
can perform this operation.

5
00:00:21,360 --> 00:00:22,350
So which means that,

6
00:00:22,350 --> 00:00:27,180
if you run a server like that,
then anybody can come into your server and

7
00:00:27,180 --> 00:00:33,420
start manipulating the information
that is present within your database.

8
00:00:33,420 --> 00:00:36,578
This is obviously a dangerous situation.

9
00:00:36,578 --> 00:00:40,380
The way that server should
be implemented is that,

10
00:00:40,380 --> 00:00:44,330
you need to have some
kind of restriction on

11
00:00:44,330 --> 00:00:48,660
which kinds of users will be allowed
to perform which kinds of operations.

12
00:00:48,660 --> 00:00:51,090
So maybe, you would allow and

13
00:00:51,090 --> 00:00:54,650
an authorized user only to
perform GET operations.

14
00:00:54,650 --> 00:01:00,040
So for example, if you want a guest
to be able to see information

15
00:01:00,040 --> 00:01:04,860
about the dishes in your restaurant or
the menu of your restaurant and

16
00:01:04,860 --> 00:01:07,250
so on, that is perfectly acceptable.

17
00:01:07,250 --> 00:01:11,699
But, you may allow only
an administrator to go in and

18
00:01:11,699 --> 00:01:17,780
modify the information about the dish or
to delete a dish from the menu.

19
00:01:17,780 --> 00:01:23,448
And also update an existing dish
in the menu, or a promotion,

20
00:01:23,448 --> 00:01:29,062
or the information about
the leaders in your server-side.

21
00:01:29,062 --> 00:01:34,810
Now, you could also have another group
of users which will be registered users

22
00:01:34,810 --> 00:01:39,980
who may be allowed to save some of
their dishes as their favorite dishes,

23
00:01:39,980 --> 00:01:44,290
and only they would be able to manipulate
the list of their favorite dishes.

24
00:01:44,290 --> 00:01:47,850
So that is another level
of authorization or

25
00:01:47,850 --> 00:01:49,940
authentication that you need to perform.

26
00:01:49,940 --> 00:01:53,400
So, you have different grades of users,
and

27
00:01:53,400 --> 00:01:57,820
also, depending on what kind of operations
they would be allowed to perform.

28
00:01:57,820 --> 00:02:01,880
So all this means is that you need
some kind of security to be built

29
00:02:01,880 --> 00:02:03,840
into your server-side.

30
00:02:03,840 --> 00:02:07,970
We'll look at how we can
authenticate users, and

31
00:02:07,970 --> 00:02:13,110
then decide what kind
of user this client is.

32
00:02:13,110 --> 00:02:15,410
And then depending on
the type of the user,

33
00:02:15,410 --> 00:02:19,360
you can allow the user to perform
certain kinds of operations.

34
00:02:19,360 --> 00:02:24,630
We will start with the basic
understanding of this, what we call as

35
00:02:24,630 --> 00:02:30,860
Basic Authentication in a server-side for

36
00:02:30,860 --> 00:02:36,940
a client, and then, build upon that
throughout the rest of this module.

37
00:02:36,940 --> 00:02:42,030
And then at the end of this module,
we will end up with a mechanism,

38
00:02:42,030 --> 00:02:46,170
thereby, allowing users
to register themselves.

39
00:02:46,170 --> 00:02:50,220
And, registered users can
perform certain operations

40
00:02:50,220 --> 00:02:53,930
that an unregistered user cannot,
and so on.

41
00:02:53,930 --> 00:02:57,320
So we'll impose various
kinds of access controls for

42
00:02:57,320 --> 00:03:01,990
various operations on the server-side
based upon the kind of user.

43
00:03:01,990 --> 00:03:04,930
So that sets you the perspective, or

44
00:03:04,930 --> 00:03:09,830
rather the idea of what you
will encounter in this module.

45
00:03:09,830 --> 00:03:12,450
Let's start with basic authentication,

46
00:03:12,450 --> 00:03:18,450
the very basic mechanism that will
enable us to authenticate users.

47
00:03:19,970 --> 00:03:25,173
Basic authentication in HTTP
is a very simple mechanism,

48
00:03:25,173 --> 00:03:28,782
which will ask the user for
a user name and

49
00:03:28,782 --> 00:03:32,720
password to be submitted with a request.

50
00:03:32,720 --> 00:03:35,180
And there is a specific structure

51
00:03:35,180 --> 00:03:39,920
on how this information will be sent
from the client to the server-side.

52
00:03:39,920 --> 00:03:45,060
So, this is a matter, the basic access
authentication, which HTTP supports,

53
00:03:45,060 --> 00:03:49,860
is a matter that will enable a server
to challenge a client, and ask for

54
00:03:49,860 --> 00:03:53,110
the username and
password to be submitted by the client.

55
00:03:53,110 --> 00:03:57,714
So the server can challenge the client
to authenticate itself by typing in this

56
00:03:57,714 --> 00:03:59,140
information.

57
00:03:59,140 --> 00:04:01,880
The client needs to send the username and

58
00:04:01,880 --> 00:04:05,440
password in response to
the challenge from the server-side.

59
00:04:05,440 --> 00:04:09,870
So, every request message
originating from a client

60
00:04:09,870 --> 00:04:13,870
should include the encoded
form of the username and

61
00:04:13,870 --> 00:04:19,700
password in the request header that
goes from the client to the server-side.

62
00:04:19,700 --> 00:04:22,229
So when the server receives the request,

63
00:04:22,229 --> 00:04:27,009
the server will extract this information
from the client's request header.

64
00:04:27,009 --> 00:04:31,831
And then, use that for
authenticating the client before

65
00:04:31,831 --> 00:04:37,390
allowing access to the various
operations on the server-side.

66
00:04:37,390 --> 00:04:40,850
So, how does this authentication work?

67
00:04:40,850 --> 00:04:44,450
If a client sends a request to the server,
and

68
00:04:44,450 --> 00:04:50,150
this client request does not include the
authorization formation, then the server

69
00:04:50,150 --> 00:04:55,160
will challenge the client, they're asking
for the client to submit this information.

70
00:04:55,160 --> 00:04:58,100
The server challenges
the client by including

71
00:04:58,100 --> 00:05:01,900
a header into the reply message coming in.

72
00:05:01,900 --> 00:05:06,410
The header with the type
as WWW-Authenticate, and

73
00:05:06,410 --> 00:05:11,843
then the second part where it
specifies the type is where it will

74
00:05:11,843 --> 00:05:17,500
specify what kind of authentication
the client needs to submit.

75
00:05:17,500 --> 00:05:21,990
And we will start with the understanding
of basic authentication here.

76
00:05:21,990 --> 00:05:26,400
And also notice that the reply
message will contain a 401 error code,

77
00:05:27,570 --> 00:05:31,270
which is unauthorized,
which stands for unauthorized.

78
00:05:31,270 --> 00:05:35,470
So when the reply comes back from
the server-side, then the client,

79
00:05:35,470 --> 00:05:41,300
in response to this reply coming in, the
client will have to send their request,

80
00:05:41,300 --> 00:05:49,550
including a specific header field in the
request message of the type authorization.

81
00:05:49,550 --> 00:05:55,250
And this authorization header field
will contain some information in there.

82
00:05:55,250 --> 00:06:00,440
For a basic authentication,
this information would be in the form of,

83
00:06:00,440 --> 00:06:03,900
as the first word here, will be Basic.

84
00:06:03,900 --> 00:06:11,410
And then followed by a space here, and
followed by a Base64 encoded string here.

85
00:06:11,410 --> 00:06:15,358
This Base64 encoded string
encodes the username and

86
00:06:15,358 --> 00:06:21,350
password in a particular format, and
then includes that in the header.

87
00:06:21,350 --> 00:06:25,479
Now you're saying, if you send
out a request message like this,

88
00:06:25,479 --> 00:06:29,397
including this, in the header,
then anybody in the middle.

89
00:06:29,397 --> 00:06:33,538
So if you know anything about security and

90
00:06:33,538 --> 00:06:39,927
how man in the middle attacks
can be launched, then obviously,

91
00:06:39,927 --> 00:06:44,777
this can be retrieved by
an intruder in between,

92
00:06:44,777 --> 00:06:49,590
and then can be used to
fake the real client.

93
00:06:49,590 --> 00:06:52,720
Again, we are not getting into
that question at the moment.

94
00:06:52,720 --> 00:06:57,470
When I talk about HTTPS
in the next module,

95
00:06:57,470 --> 00:07:00,880
I will come back to address that
issue in a bit more detail.

96
00:07:00,880 --> 00:07:06,060
But for the moment, the information
in the header will be sent over

97
00:07:07,880 --> 00:07:11,930
without being encrypted in
the header at this moment.

98
00:07:11,930 --> 00:07:15,460
Now, one other reason why I'm doing this
is that, so that we can actually look at

99
00:07:15,460 --> 00:07:20,150
the header directly and then see this
information in the header itself.

100
00:07:20,150 --> 00:07:25,401
So, when the client sends this request,
then the server will extract

101
00:07:25,401 --> 00:07:30,930
the information from this authorization
header in the request header.

102
00:07:30,930 --> 00:07:35,078
And then use this information in
order to verify whether this is

103
00:07:35,078 --> 00:07:37,670
an authorized a client request or not.

104
00:07:37,670 --> 00:07:40,412
Now of course your next question would be,

105
00:07:40,412 --> 00:07:44,490
what exactly does this
authorization header contain?

106
00:07:44,490 --> 00:07:48,350
The authorization header itself
is constructed as follows.

107
00:07:48,350 --> 00:07:52,180
If you have a username and
a password, these are the two

108
00:07:52,180 --> 00:07:55,730
pieces of information that you
will use to authenticate a client.

109
00:07:55,730 --> 00:08:01,330
So the username and password will be
concatenated into a single string

110
00:08:01,330 --> 00:08:06,910
by saying username and a colon,
and the password itself.

111
00:08:06,910 --> 00:08:09,860
So the username string, colon and

112
00:08:09,860 --> 00:08:16,210
password will be concatenated
together into an entire string here.

113
00:08:16,210 --> 00:08:22,994
This resulting string that we get here
is that, encoded using Base64 encode.

114
00:08:22,994 --> 00:08:27,344
If you know about how encoding
is done basics for encoding,

115
00:08:27,344 --> 00:08:32,390
convert that into an ASCII header
like as shown in this example here,

116
00:08:32,390 --> 00:08:36,195
so this is nothing but
a string of ASCII headers.

117
00:08:36,195 --> 00:08:39,545
Now if you don't know much about basic
stiff encoding, don't worry about it,

118
00:08:39,545 --> 00:08:44,325
it doesn't impact your understanding
of what is going on here anyway.

119
00:08:44,325 --> 00:08:47,090
So this Basic64 encoded strings, so

120
00:08:47,090 --> 00:08:51,950
this particular information is
encoded into a string like this, and

121
00:08:51,950 --> 00:08:57,090
then enclosed in the request header
going from the client to the server.

122
00:08:57,090 --> 00:09:02,143
The request header itself is
of the type authorization,

123
00:09:02,143 --> 00:09:07,194
and then followed by the actual
value here, which says,

124
00:09:07,194 --> 00:09:13,774
Basic, and a space here, and
the Base64 encoded string here.

125
00:09:13,774 --> 00:09:20,034
So, when this is received by our sever,
the server will extract this information,

126
00:09:20,034 --> 00:09:25,059
and then from here, it'll extract
the username and password, and

127
00:09:25,059 --> 00:09:31,620
then verify whether that matches an
authorized user or not on the server-side.

128
00:09:31,620 --> 00:09:36,917
To help you better understand how we
actually organize the express application

129
00:09:36,917 --> 00:09:42,211
and how the authentication itself is
carried out, as we have learned earlier,

130
00:09:42,211 --> 00:09:47,520
express applications themselves
are organized in a set of middleware.

131
00:09:47,520 --> 00:09:51,690
And the way the express application
works is that the middleware

132
00:09:51,690 --> 00:09:55,630
are applied to the request and
the response message

133
00:09:55,630 --> 00:10:00,940
in the order in which it is
declared in my express application.

134
00:10:00,940 --> 00:10:05,290
So if you have a express.use and

135
00:10:05,290 --> 00:10:09,740
then you have the first one saying
a static server, then after that,

136
00:10:09,740 --> 00:10:13,220
you have another middleware, then after
that, you have another middleware.

137
00:10:13,220 --> 00:10:18,560
The sequence in which they are declared
in the express servers app.js file,

138
00:10:18,560 --> 00:10:23,600
for example, is the exact sequence in
which the middleware will be applied.

139
00:10:23,600 --> 00:10:29,124
So an incoming request from the
server-side as you recall in your express

140
00:10:29,124 --> 00:10:34,690
application, the incoming request
is treated as a request object.

141
00:10:34,690 --> 00:10:39,050
The response object is what
the express server constructs, and

142
00:10:39,050 --> 00:10:43,310
then the next is allows you to
go on to the next middleware

143
00:10:43,310 --> 00:10:45,910
that you're going to be applying,
and so on.

144
00:10:45,910 --> 00:10:52,400
So, an incoming request like this, when it
comes in, the first middleware is applied.

145
00:10:52,400 --> 00:10:56,164
And then once that middleware has
transformed both the request and

146
00:10:56,164 --> 00:11:00,680
the response, it moves on to the next
middleware, which is then applied to it.

147
00:11:00,680 --> 00:11:03,940
So for example,
we saw that we applied Morgan first,

148
00:11:03,940 --> 00:11:06,930
then we applied body
parser to the middleware.

149
00:11:06,930 --> 00:11:12,930
So they must have already transformed
the request and the response objects.

150
00:11:12,930 --> 00:11:17,440
And then after that, we can include an
authentication middleware in place there.

151
00:11:17,440 --> 00:11:22,260
The authentication middleware is
going to authenticate the request.

152
00:11:22,260 --> 00:11:26,950
Now, so if you are using basic
authentication, do your request

153
00:11:26,950 --> 00:11:31,970
must contain in the header the
authorization header in place in there.

154
00:11:31,970 --> 00:11:36,260
So the authorization header will be
extracted by the authentication middleware

155
00:11:36,260 --> 00:11:40,180
and then checked to see if
the user is authorized.

156
00:11:40,180 --> 00:11:46,099
And if the authentication middleware
detects that you are an authorized user,

157
00:11:46,099 --> 00:11:50,515
then you'll be allowed to proceed
forward to the next set of

158
00:11:50,515 --> 00:11:54,427
middleware that follows
the authentication step.

159
00:11:54,427 --> 00:11:58,510
And your records will be processed
by the subsequent middleware.

160
00:11:58,510 --> 00:11:59,519
But other hand,

161
00:11:59,519 --> 00:12:04,422
if your authentication middleware decides
that you are not an authorized user,

162
00:12:04,422 --> 00:12:09,197
then the authentication middleware will
take you along a different path off.

163
00:12:09,197 --> 00:12:13,975
And then generate an error,
and then send back

164
00:12:13,975 --> 00:12:19,368
an appropriate error reply
to that client-side and

165
00:12:19,368 --> 00:12:24,010
will be redirected to the error handler.

166
00:12:24,010 --> 00:12:28,450
So this redirection to the error
handler will be done by calling Next

167
00:12:28,450 --> 00:12:32,490
with the error as the parameter
to that Next here.

168
00:12:32,490 --> 00:12:38,240
So the Next is exactly this Next that we
see in the request resource Next here.

169
00:12:38,240 --> 00:12:42,760
And so, that will take you all
the way down to the error handler,

170
00:12:42,760 --> 00:12:48,170
which will handle error and then send back
the error message back to the client-side,

171
00:12:48,170 --> 00:12:51,820
indicating the failure
of the authentication.

172
00:12:51,820 --> 00:12:56,720
So this is how your typical
basic authorization, or

173
00:12:56,720 --> 00:13:03,435
basic authentication works in
your server-side application.

174
00:13:03,435 --> 00:13:08,305
Having understood this,
let's move on to the exercise where we

175
00:13:08,305 --> 00:13:13,176
will implement the basic
authentication in our application and

176
00:13:13,176 --> 00:13:15,717
see how it authenticates users.

177
00:13:15,717 --> 00:13:17,952
[MUSIC]