1
00:00:00,570 --> 00:00:03,450
-: So what exactly is Oauth2?

2
00:00:03,450 --> 00:00:06,568
So O of two is a standard protocol for authentication

3
00:00:06,568 --> 00:00:09,180
and authorization and,

4
00:00:09,180 --> 00:00:12,900
is widely used mainly in web apps.

5
00:00:12,900 --> 00:00:16,530
Now the OAuth2 protocol has many moving parts,

6
00:00:16,530 --> 00:00:18,300
and is quite complicated to implement,

7
00:00:18,300 --> 00:00:21,850
but we will discuss only the high level details.

8
00:00:21,850 --> 00:00:25,552
So to understand how exactly OAuth2 is working

9
00:00:25,552 --> 00:00:30,367
let's first review the OAuth2 protocol components.

10
00:00:30,367 --> 00:00:33,176
So the first one is naturally the user.

11
00:00:33,176 --> 00:00:35,070
The user is some, again

12
00:00:35,070 --> 00:00:39,570
end user who wants to access protected resources in the api.

13
00:00:39,570 --> 00:00:41,670
In other words, this is someone

14
00:00:41,670 --> 00:00:44,829
and it can be a human being or a software,

15
00:00:44,829 --> 00:00:46,770
that wants access

16
00:00:46,770 --> 00:00:48,870
to a resource that is protected

17
00:00:48,870 --> 00:00:51,229
with authentication and authorization mechanism.

18
00:00:51,229 --> 00:00:53,858
The next component is the client app.

19
00:00:53,858 --> 00:00:57,210
This client application is the application

20
00:00:57,210 --> 00:00:58,898
that is accessing the api.

21
00:00:58,898 --> 00:01:02,340
So the user is using the client app

22
00:01:02,340 --> 00:01:06,086
in order to access the API that is on the server.

23
00:01:06,086 --> 00:01:09,750
The next one is the authorization server.

24
00:01:09,750 --> 00:01:12,660
Now the authorization server is a specialized

25
00:01:12,660 --> 00:01:16,170
server that is used to authorize the user

26
00:01:16,170 --> 00:01:17,490
for the client application.

27
00:01:17,490 --> 00:01:21,330
So the authorization server identifies the user

28
00:01:21,330 --> 00:01:24,194
using whatever method of identification it supports

29
00:01:24,194 --> 00:01:26,850
and tells back the client

30
00:01:26,850 --> 00:01:28,350
app who the user is and,

31
00:01:28,350 --> 00:01:29,974
what is he allowed to do.

32
00:01:29,974 --> 00:01:33,330
And the last component is the resource server.

33
00:01:33,330 --> 00:01:37,383
which is actually the API itself that we want to access.

34
00:01:37,383 --> 00:01:39,383
Okay, so we have the four components,

35
00:01:39,383 --> 00:01:41,010
the user, the client app

36
00:01:41,010 --> 00:01:43,628
the authorization server, and the resource server.

37
00:01:43,628 --> 00:01:46,112
And now let's see the complete flow

38
00:01:46,112 --> 00:01:50,133
of Oauth 2 and how all these components work together.

39
00:01:52,050 --> 00:01:53,122
So we have the client up,

40
00:01:53,122 --> 00:01:55,728
and we have the resource server.

41
00:01:55,728 --> 00:01:57,630
The first thing in the flow is

42
00:01:57,630 --> 00:02:00,937
that the client app calls the API anonymously

43
00:02:00,937 --> 00:02:04,170
without passing any identification data.

44
00:02:04,170 --> 00:02:08,039
The resource server identifies that the call is anonymous

45
00:02:08,039 --> 00:02:10,080
and that no user data is passed,

46
00:02:10,080 --> 00:02:11,845
and it tells the client app

47
00:02:11,845 --> 00:02:15,919
to redirect to authorization server.

48
00:02:15,919 --> 00:02:19,499
The authorization server asks user to grant permission.

49
00:02:19,499 --> 00:02:22,447
Of course, after identifying the user

50
00:02:22,447 --> 00:02:27,210
and returns an access token to the client app.

51
00:02:27,210 --> 00:02:30,025
This access token contains the data that is needed

52
00:02:30,025 --> 00:02:32,180
by the resource server, the api

53
00:02:32,180 --> 00:02:35,220
in order to identify the user and to figure

54
00:02:35,220 --> 00:02:38,401
out what exactly the user is allowed to do.

55
00:02:38,401 --> 00:02:40,647
The next and the last step

56
00:02:40,647 --> 00:02:43,830
of the OAuth2 flow is that the client app

57
00:02:43,830 --> 00:02:46,447
sends the access token to the resource server

58
00:02:46,447 --> 00:02:49,630
and now the resource server knows who the user is

59
00:02:49,630 --> 00:02:53,400
and whether he is allowed to access the api.

60
00:02:53,400 --> 00:02:55,462
So if this sounds a little bit complicated

61
00:02:55,462 --> 00:02:58,440
let's see a demo of this flow, and I'm sure

62
00:02:58,440 --> 00:03:02,336
that after that the whole process will be much clearer.

63
00:03:02,336 --> 00:03:04,194
So we will demonstrate OAuth2

64
00:03:04,194 --> 00:03:06,547
using a site called Feedly.

65
00:03:06,547 --> 00:03:08,515
I dunno if you know of Feedly,

66
00:03:08,515 --> 00:03:12,210
but Feedly is one of the best RSS clients

67
00:03:12,210 --> 00:03:13,043
in the web,

68
00:03:13,043 --> 00:03:14,940
and I highly recommend you to use it.

69
00:03:14,940 --> 00:03:17,620
RSS clients are clients that are subscribed

70
00:03:17,620 --> 00:03:20,490
to blogs and they are a great resource

71
00:03:20,490 --> 00:03:23,432
of learning in any field of knowledge you would like.

72
00:03:23,432 --> 00:03:26,784
I'm using Feedly almost every day to learn new things

73
00:03:26,784 --> 00:03:29,023
about api, about software architecture

74
00:03:29,023 --> 00:03:30,832
about technological advancement

75
00:03:30,832 --> 00:03:33,275
about public speaking, and lots more.

76
00:03:33,275 --> 00:03:35,081
So again, highly recommended.

77
00:03:35,081 --> 00:03:38,549
Now, when browsing the Feedly homepage,

78
00:03:38,549 --> 00:03:41,490
you will be presented with this page.

79
00:03:41,490 --> 00:03:44,973
And now let's click on login.

80
00:03:46,020 --> 00:03:46,980
What happens now,

81
00:03:46,980 --> 00:03:50,310
is that Feedly asks us how do we want to login.

82
00:03:50,310 --> 00:03:51,836
So if you remember from our flow

83
00:03:51,836 --> 00:03:56,033
we say that the server is redirecting the client app

84
00:03:56,033 --> 00:03:57,742
to an authorization server.

85
00:03:57,742 --> 00:04:01,110
So basically what is happening here is that Feedly

86
00:04:01,110 --> 00:04:05,550
asks us which authorization server do we want to use.

87
00:04:05,550 --> 00:04:07,953
So I'll go with Facebook.

88
00:04:09,900 --> 00:04:12,120
So again, Facebook here is functioning

89
00:04:12,120 --> 00:04:14,163
as an authorization server.

90
00:04:15,330 --> 00:04:16,653
And I'll log in.

91
00:04:31,977 --> 00:04:34,553
And now I'm logged into Feedly.

92
00:04:34,553 --> 00:04:35,871
So basically,

93
00:04:35,871 --> 00:04:37,177
Facebook told Feedly,

94
00:04:37,177 --> 00:04:38,881
I know who this guy is

95
00:04:38,881 --> 00:04:41,562
you can see down here

96
00:04:41,562 --> 00:04:42,870
the picture of me.

97
00:04:42,870 --> 00:04:44,511
So Freedly knows who I am,

98
00:04:44,511 --> 00:04:46,651
and now I am logged into feedly.

99
00:04:46,651 --> 00:04:50,369
without Feedly doing anything related to the identification.

100
00:04:50,369 --> 00:04:52,850
So basically what happened here is

101
00:04:52,850 --> 00:04:56,852
that Facebook identified me for Feedly

102
00:04:56,852 --> 00:05:00,213
and returned this information to Feedly.

103
00:05:01,680 --> 00:05:04,920
Now, in order to make this flow walk the OAuth2

104
00:05:04,920 --> 00:05:07,024
flow walk the authorization server.

105
00:05:07,024 --> 00:05:10,350
Facebook in our example, should be familiar

106
00:05:10,350 --> 00:05:13,964
with the resource server or Feedly again, in our scenario

107
00:05:13,964 --> 00:05:17,480
because when Feedly redirected me to Facebook

108
00:05:17,480 --> 00:05:19,323
then he basically told Facebook,

109
00:05:19,323 --> 00:05:20,963
Listen, I'm Feedly,

110
00:05:20,963 --> 00:05:24,180
and I want you to identify this user

111
00:05:24,180 --> 00:05:27,360
for me and then return the information to Feedly.

112
00:05:27,360 --> 00:05:30,135
So Facebook should be familiar with Feedly.

113
00:05:30,135 --> 00:05:31,665
So in order to do that,

114
00:05:31,665 --> 00:05:33,244
the resource server

115
00:05:33,244 --> 00:05:36,698
must register itself with the authorization server.

116
00:05:36,698 --> 00:05:38,229
So this process is called

117
00:05:38,229 --> 00:05:40,100
the app registration,

118
00:05:40,100 --> 00:05:44,124
and in this process the resource server comes

119
00:05:44,124 --> 00:05:47,248
to authorization server and registers itself.

120
00:05:47,248 --> 00:05:50,726
The registration process includes filling some data

121
00:05:50,726 --> 00:05:53,914
about the resource server, mainly the name

122
00:05:53,914 --> 00:05:57,617
and the URL address to which the authorization server

123
00:05:57,617 --> 00:06:01,035
should access to return the information about the user.

124
00:06:01,035 --> 00:06:02,156
So let's see a demo

125
00:06:02,156 --> 00:06:05,313
on the how app registration process is working.

126
00:06:06,390 --> 00:06:09,259
Now I'm going to demonstrate the app registration process

127
00:06:09,259 --> 00:06:10,937
with GitHub.

128
00:06:10,937 --> 00:06:13,782
GitHub can also be used as an authorization server

129
00:06:13,782 --> 00:06:15,300
for OAuth2 ,

130
00:06:15,300 --> 00:06:17,778
which means that it has an app registration page.

131
00:06:17,778 --> 00:06:21,242
So this is the app registration page in GitHub.

132
00:06:21,242 --> 00:06:23,272
So I'll just type in the details

133
00:06:23,272 --> 00:06:25,231
of the application I want to register.

134
00:06:25,231 --> 00:06:27,933
This is of course a fictional application.

135
00:06:29,130 --> 00:06:31,770
So let's type in the application details.

136
00:06:31,770 --> 00:06:34,540
So the application name will be order

137
00:06:35,750 --> 00:06:38,336
management ,the homepage will be

138
00:06:38,336 --> 00:06:39,640
http

139
00:06:42,120 --> 00:06:42,953
order

140
00:06:43,860 --> 00:06:45,235
manage.com.

141
00:06:45,235 --> 00:06:46,657
We'll skip the description

142
00:06:46,657 --> 00:06:49,980
and the authorization call back url.

143
00:06:49,980 --> 00:06:52,530
So this is maybe the most important part

144
00:06:52,530 --> 00:06:54,513
in the application registration process.

145
00:06:54,513 --> 00:06:58,328
If you remember from our discussion on the OAuth2 flow

146
00:06:58,328 --> 00:07:02,790
after the authorization server authorizes the user,

147
00:07:02,790 --> 00:07:05,712
it should tell back the application who the user is and,

148
00:07:05,712 --> 00:07:07,950
what is he allowed to do.

149
00:07:07,950 --> 00:07:09,600
So the way to do it is

150
00:07:09,600 --> 00:07:13,697
that the authorization server calls a specific call back URL

151
00:07:13,697 --> 00:07:16,653
of the application passing in this data.

152
00:07:16,653 --> 00:07:19,693
So this is URL will be specifying

153
00:07:19,693 --> 00:07:21,190
and it will be

154
00:07:25,050 --> 00:07:29,551
order manage.com/callback.

155
00:07:29,551 --> 00:07:33,472
So this is the URL the authorization server will call,

156
00:07:33,472 --> 00:07:35,943
after authorizing the user.

157
00:07:37,170 --> 00:07:40,680
So let's click register application

158
00:07:40,680 --> 00:07:43,001
and the application is registered

159
00:07:43,001 --> 00:07:45,467
and we see some data about application.

160
00:07:45,467 --> 00:07:49,354
Now, the most important things to note about this page,

161
00:07:49,354 --> 00:07:52,610
are the client ID and,

162
00:07:52,610 --> 00:07:55,140
the client secret.

163
00:07:55,140 --> 00:07:57,494
Those two keys must be passed

164
00:07:57,494 --> 00:08:01,580
to the authorization server when asking for authorization so

165
00:08:01,580 --> 00:08:05,190
that the authorization server will know which

166
00:08:05,190 --> 00:08:08,532
application is requesting the user authorization.

167
00:08:08,532 --> 00:08:11,693
Okay, so we talked about the Coauthor flow

168
00:08:11,693 --> 00:08:14,520
and we talked about the application registration.

169
00:08:14,520 --> 00:08:15,843
And now let's move on.