1
00:00:03,620 --> 00:00:09,015
Я уверен, что у вас есть одна или несколько аккаунтов в социальных сетях.

2
00:00:09,015 --> 00:00:13,920
Будь то Facebook, Twitter, YouTube, Google, GitHub

3
00:00:13,920 --> 00:00:19,760
или многие другие поставщики услуг, где вы зарегистрировали телефон и учетную запись.

4
00:00:19,760 --> 00:00:22,545
Теперь эти поставщики услуг, в свою очередь,

5
00:00:22,545 --> 00:00:27,480
готовы предоставлять услуги аутентификации от вашего имени.

6
00:00:27,480 --> 00:00:32,880
Так, например, вы видите распространение ряда веб-сайтов

7
00:00:32,880 --> 00:00:37,440
и мобильных приложений, в которых вам разрешено входить

8
00:00:37,440 --> 00:00:40,260
с помощью ваших учетных записей в социальных сетях.

9
00:00:40,260 --> 00:00:42,805
Итак, как это на самом деле работает?

10
00:00:42,805 --> 00:00:47,270
Многие из этих поставщиков учетных записей в социальных сетях действуют в

11
00:00:47,270 --> 00:00:53,945
качестве поставщиков услуг аутентификации, используя протокол OAuth.

12
00:00:53,945 --> 00:01:00,660
Мы рассмотрим OAuth и то, как он позволяет этим сторонним поставщикам аутентификации

13
00:01:00,660 --> 00:01:04,995
предоставлять аутентификацию от вашего имени,

14
00:01:04,995 --> 00:01:14,183
а также позволяет вам входить в другие службы, используя свои учетные записи в социальных сетях.

15
00:01:14,183 --> 00:01:18,510
Я уверен, что вы, возможно, слышали о OAuth 1 и OAuth 2 и,

16
00:01:18,510 --> 00:01:21,370
возможно, слышали от людей, говорящих,

17
00:01:21,370 --> 00:01:24,669
что Facebook обеспечивает аутентификацию на основе OAuth 2,

18
00:01:24,669 --> 00:01:28,450
или Google обеспечивает аутентификацию на основе OAuth 2 и т. Д.

19
00:01:28,450 --> 00:01:29,800
Я уверен, что вам должно быть интересно,

20
00:01:29,800 --> 00:01:35,240
что именно эти OAuth1 и OAuth 2 должны быть?

21
00:01:35,240 --> 00:01:40,090
Теперь OAuth1 и OAuth 2 являются фреймворками авторизации

22
00:01:40,090 --> 00:01:42,920
, которые основаны на открытых стандартах.

23
00:01:42,920 --> 00:01:46,110
И они могут быть использованы через Интернет для аутентификации

24
00:01:46,110 --> 00:01:50,375
вашей личности на многих веб-сайтах или мобильных приложениях.

25
00:01:50,375 --> 00:01:52,475
Теперь, когда вы используете эти сервисы,

26
00:01:52,475 --> 00:01:56,470
вы зависите от одной из учетных записей в социальных сетях, таких как Facebook

27
00:01:56,470 --> 00:01:58,525
, Google, Twitter, Microsoft, Instagram

28
00:01:58,525 --> 00:02:02,380
, GitHub, Digitalocean и многие

29
00:02:02,380 --> 00:02:06,915
другие, которые предоставляют эти услуги аутентификации для других пользователей.

30
00:02:06,915 --> 00:02:10,465
Эти поставщики услуг аутентификации обещают

31
00:02:10,465 --> 00:02:15,310
пользователям этой службы аутентификации, что они проведут

32
00:02:15,310 --> 00:02:18,535
подлинность личности пользователя на основе предоставления им

33
00:02:18,535 --> 00:02:24,100
своих учетных данных для этих служб социальных сетей.

34
00:02:24,100 --> 00:02:28,630
Теперь есть дополнительный сервис OpenID.

35
00:02:28,630 --> 00:02:34,220
Но, конечно, не связано с OAuth, но предоставляет аналогичный вид обслуживания.

36
00:02:34,220 --> 00:02:38,005
Но большинство стандартных поставщиков социальных сетей,

37
00:02:38,005 --> 00:02:39,835
как вы увидите здесь,

38
00:02:39,835 --> 00:02:44,290
предоставляют услуги на основе OAuth 2 в наши дни.

39
00:02:44,290 --> 00:02:48,760
Теперь, как я уже упоминал, OAuth1 и OAuth 2 являются протоколами аутентификации,

40
00:02:48,760 --> 00:02:53,010
а OAuth 1 был первым протоколом, который появился.

41
00:02:53,010 --> 00:02:55,165
Это произошло из Твиттера,

42
00:02:55,165 --> 00:02:58,725
за которым стоит Блейн Кук,

43
00:02:58,725 --> 00:03:04,330
и это документировано в Инженерной группе Интернета, RFC 5849.

44
00:03:04,330 --> 00:03:08,235
Итак, если вы хотите прочитать подробные сведения о том, как работают эти протоколы,

45
00:03:08,235 --> 00:03:11,350
это место, чтобы найти это.

46
00:03:11,350 --> 00:03:18,430
Протокол OAuth 2 эволюционировал из OAuth 1, чтобы сделать его более простым

47
00:03:18,430 --> 00:03:23,420
и более простым способом для разработки клиентов.

48
00:03:23,420 --> 00:03:29,050
И это документировано в IETF RFC 6749, и после этого

49
00:03:29,050 --> 00:03:35,975
в IETF RFC 6750 появилось еще одно использование токенов на предъявителя.

50
00:03:35,975 --> 00:03:38,155
Теперь, с нашей точки зрения,

51
00:03:38,155 --> 00:03:42,926
мы не хотим вдаваться в подробности того, как эти протоколы действительно работают.

52
00:03:42,926 --> 00:03:45,640
Вместо этого все, что нас интересует, это то,

53
00:03:45,640 --> 00:03:51,505
как мы используем их для аутентификации пользователей в нашем веб-приложении

54
00:03:51,505 --> 00:03:53,460
или в нашем мобильном приложении,

55
00:03:53,460 --> 00:03:56,215
когда нам нужно аутентифицировать пользователя

56
00:03:56,215 --> 00:03:59,965
на экспресс-сервере, на котором мы работали до сих пор?

57
00:03:59,965 --> 00:04:04,330
Теперь мы в первую очередь сосредоточимся на OAuth 2

58
00:04:04,330 --> 00:04:05,710
, потому что в упражнении

59
00:04:05,710 --> 00:04:10,960
мы рассмотрим использование Facebook в качестве поставщика услуг аутентификации OAuth 2,

60
00:04:10,960 --> 00:04:13,870
и здесь нам нужно понять

61
00:04:13,870 --> 00:04:19,810
несколько терминов, чтобы увидеть, как именно работает этот протокол OAuth 2.

62
00:04:19,810 --> 00:04:25,065
По крайней мере, данные о том, как работает сам протокол.

63
00:04:25,065 --> 00:04:26,995
Теперь, в случае OAuth 2,

64
00:04:26,995 --> 00:04:30,440
мы всегда говорим о собственности на ресурсы.

65
00:04:30,440 --> 00:04:32,200
Теперь в этом случае

66
00:04:32,200 --> 00:04:34,810
ресурс, на который я имею в виду, не является

67
00:04:34,810 --> 00:04:37,870
ресурсом, который хранится на сервере Express.

68
00:04:37,870 --> 00:04:39,655
Вместо этого ресурс, на который мы ссылаемся здесь,

69
00:04:39,655 --> 00:04:42,055
является идентификацией пользователя.

70
00:04:42,055 --> 00:04:45,760
Теперь любой сервер, как и сервер Express, который мы создавали,

71
00:04:45,760 --> 00:04:48,310
хочет получить доступ к этому ресурсу,

72
00:04:48,310 --> 00:04:50,000
то есть вашей личности.

73
00:04:50,000 --> 00:04:51,760
Итак, где ваша личность?

74
00:04:51,760 --> 00:04:54,160
Ваша личность хранится на одном из

75
00:04:54,160 --> 00:04:58,457
таких поставщиков услуг аутентификации в социальных сетях, как Facebook и так далее,

76
00:04:58,457 --> 00:05:03,140
потому что вы уже создали учетную запись на этих сайтах социальных сетей.

77
00:05:03,140 --> 00:05:06,920
Таким образом, ваша информация или ваша идентификационная информация или

78
00:05:06,920 --> 00:05:11,020
информация вашего профиля хранятся, например, в Facebook.

79
00:05:11,020 --> 00:05:15,550
Теперь ваш Express сервер хочет получить доступ к вашей личности и

80
00:05:15,550 --> 00:05:20,650
убедиться, что это действительно вы пытаетесь получить доступ к серверу Express.

81
00:05:20,650 --> 00:05:22,000
Таким образом, в данном случае,

82
00:05:22,000 --> 00:05:24,690
Экспресс сервер, который мы разработали,

83
00:05:24,690 --> 00:05:27,390
выступает в качестве клиентского приложения.

84
00:05:27,390 --> 00:05:29,170
Таким образом, это где клиентское приложение,

85
00:05:29,170 --> 00:05:33,265
то есть веб-сайт или мобильное приложение, которое хочет получить

86
00:05:33,265 --> 00:05:38,905
доступ к серверу ресурсов для того, чтобы получить информацию о вас.

87
00:05:38,905 --> 00:05:41,530
Что такое сервер ресурсов, о котором мы говорим?

88
00:05:41,530 --> 00:05:45,730
Это сервер аутентификации OAuth Facebook,

89
00:05:45,730 --> 00:05:49,870
который также предоставляет информацию о вашем профиле по запросу.

90
00:05:49,870 --> 00:05:54,490
Теперь, конечно, вы не будете произвольно распространять информацию о вашем профиле.

91
00:05:54,490 --> 00:06:00,370
Вместо этого вы хотите иметь возможность убедиться, что вы предоставляете доступ к

92
00:06:00,370 --> 00:06:08,250
информации профиля поставщику услуг, прошедшему проверку подлинности, или серверу, прошедшему проверку подлинности.

93
00:06:08,250 --> 00:06:12,610
Теперь,

94
00:06:12,610 --> 00:06:18,535
например, ваше клиентское приложение или сервер Express здесь будет регистрироваться на Facebook с учетной записью, говорящей, что я управляю приложением,

95
00:06:18,535 --> 00:06:25,780
и я хочу зарегистрироваться в качестве потенциального источника, который может

96
00:06:25,780 --> 00:06:29,680
подойти к вам для аутентификации пользователей, когда они предоставляют

97
00:06:29,680 --> 00:06:33,859
доступ к их профиль, который хранится на вашем сайте.

98
00:06:33,859 --> 00:06:35,335
Таким образом, сервер Express,

99
00:06:35,335 --> 00:06:37,645
в данном случае выступая в качестве клиентского приложения,

100
00:06:37,645 --> 00:06:45,790
зарегистрируется на Facebook и получит ClientiD и секрет клиента от Facebook.

101
00:06:45,790 --> 00:06:48,955
Теперь, когда сервер Express регистрируется на Facebook,

102
00:06:48,955 --> 00:06:52,240
вам нужно иметь учетную запись на Facebook,

103
00:06:52,240 --> 00:06:53,950
аутентифицированную учетную запись на Facebook,

104
00:06:53,950 --> 00:06:59,030
которую вы будете использовать для настройки этого приложения на Facebook.

105
00:06:59,030 --> 00:07:01,450
Итак, как только вы

106
00:07:01,450 --> 00:07:06,680
зарегистрируетесь, вы получите доступ к ClientiD и секрету клиента.

107
00:07:06,680 --> 00:07:08,650
Теперь сервер ресурсов,

108
00:07:08,650 --> 00:07:12,310
как я уже упоминал, является сервером, на котором хранятся защищенные данные.

109
00:07:12,310 --> 00:07:18,665
Защищенные данные означают профиль пользователя, который хочет получить доступ к серверу Express.

110
00:07:18,665 --> 00:07:22,300
Таким образом, сервер Express хочет получить доступ к этому серверу ресурсов

111
00:07:22,300 --> 00:07:28,415
и получить данные профиля пользователя, который хочет получить доступ к серверу Express.

112
00:07:28,415 --> 00:07:31,265
Итак, вы видите отношения здесь.

113
00:07:31,265 --> 00:07:33,355
Поэтому, когда я говорю о клиентском приложении,

114
00:07:33,355 --> 00:07:36,535
я имею в виду не их интерфейсное приложение,

115
00:07:36,535 --> 00:07:40,000
а их сервер Express, который пытается предоставить вам

116
00:07:40,000 --> 00:07:44,190
доступ к ресурсам, которые он имеет на своем сайте.

117
00:07:44,190 --> 00:07:45,635
Но серверу Express для

118
00:07:45,635 --> 00:07:48,940
того, чтобы вы могли получить доступ,

119
00:07:48,940 --> 00:07:53,200
потребуется доступ к вашему серверу ресурсов Facebook, который

120
00:07:53,200 --> 00:07:58,655
будет аутентифицировать вас и предоставлять информацию о вашем профиле на сервер Express.

121
00:07:58,655 --> 00:08:01,375
Итак, сервер ресурсов, о котором я говорю здесь,

122
00:08:01,375 --> 00:08:06,190
является сервером аутентификации OAuth 2 Facebook

123
00:08:06,190 --> 00:08:11,681
плюс сервер ресурсов, который дает вам доступ к информации профиля пользователя.

124
00:08:11,681 --> 00:08:16,180
Сервер авторизации — это сервер, который

125
00:08:16,180 --> 00:08:19,210
разрешит кому-либо получить доступ

126
00:08:19,210 --> 00:08:22,825
к серверу ресурсов, чтобы получить информацию о профиле.

127
00:08:22,825 --> 00:08:27,375
Теперь пользователь является тем, кто имеет информацию о профиле на сервере ресурсов.

128
00:08:27,375 --> 00:08:30,610
Пользователь должен разрешить серверу Express перейти на

129
00:08:30,610 --> 00:08:34,035
этот сервер ресурсов, чтобы получить информацию о профиле.

130
00:08:34,035 --> 00:08:37,000
Но если пользователю нужно авторизовать Express сервер,

131
00:08:37,000 --> 00:08:40,045
пользователю необходимо войти в учетную запись Facebook,

132
00:08:40,045 --> 00:08:45,115
а затем получить информацию от Facebook, вызываемую как токен доступа,

133
00:08:45,115 --> 00:08:48,995
который пользователь затем передаст на Express сервер.

134
00:08:48,995 --> 00:08:54,750
Теперь, когда токен доступа будет получен из Facebook через протокол OAuth 2,

135
00:08:54,750 --> 00:08:58,090
токен доступа будет выдан с точки зрения

136
00:08:58,090 --> 00:09:01,675
разрешения этого клиентского приложения или сервера Express,

137
00:09:01,675 --> 00:09:04,885
который уже зарегистрирован на Facebook и говорит, что

138
00:09:04,885 --> 00:09:08,020
этот клиентский сервер я авторизую для

139
00:09:08,020 --> 00:09:15,265
доступа информацию о своем профиле от своего поставщика услуг OAuth Facebook.

140
00:09:15,265 --> 00:09:18,290
Так что, опять же, это немного запутанно.

141
00:09:18,290 --> 00:09:20,940
Мы увидим диаграмму, где этот поток

142
00:09:20,940 --> 00:09:24,360
информации разъясняется вам немного более четко.

143
00:09:24,360 --> 00:09:32,380
Один момент, который я только что упомянул, касается токена OAuth или токена доступа.

144
00:09:32,380 --> 00:09:34,090
Что это за токен доступа?

145
00:09:34,090 --> 00:09:38,675
Токен доступа - это то, что сервер авторизации выдает для вас.

146
00:09:38,675 --> 00:09:40,620
Какой сервер авторизации?

147
00:09:40,620 --> 00:09:44,100
Это сторонний сервер авторизации OAuth 2,

148
00:09:44,100 --> 00:09:46,668
сервер Facebook, в этом примере.

149
00:09:46,668 --> 00:09:51,130
Таким образом, это приложение сервера Express.

150
00:09:51,130 --> 00:09:54,485
Теперь вы, как их внешний пользователь,

151
00:09:54,485 --> 00:09:58,070
хотите получить доступ к чему-то из приложения сервера Express.

152
00:09:58,070 --> 00:10:02,150
Серверное приложение Express сообщит вам, что вы

153
00:10:02,150 --> 00:10:06,666
аутентифицируетесь из Facebook, а затем получите токен доступа от Facebook.

154
00:10:06,666 --> 00:10:09,770
Этот токен доступа выдается

155
00:10:09,770 --> 00:10:16,330
пользователю front-end из Facebook, когда пользователь входит в свою учетную запись Facebook.

156
00:10:16,330 --> 00:10:21,155
Теперь этот токен доступа выдается на имя клиентского приложения,

157
00:10:21,155 --> 00:10:25,060
Express server, которое уже зарегистрировано на Facebook.

158
00:10:25,060 --> 00:10:30,485
Таким образом, для того, чтобы пользователь мог получить доступ к Facebook, чтобы получить свой токен доступа,

159
00:10:30,485 --> 00:10:36,580
пользователю требуется идентификатор клиента клиентского приложения или приложения Express.

160
00:10:36,580 --> 00:10:39,755
Таким образом, этот идентификатор клиента встроен

161
00:10:39,755 --> 00:10:44,460
в интерфейсное приложение, которое этот Express сервер будет обслуживать для вас.

162
00:10:44,460 --> 00:10:47,915
Таким образом, сервер Express обслуживает веб-сайт, к которому вы обращаетесь,

163
00:10:47,915 --> 00:10:50,820
тогда этот веб-сайт будет содержать код,

164
00:10:50,820 --> 00:10:56,597
в котором идентификатор клиента этого Express сервера уже встроен там.

165
00:10:56,597 --> 00:11:00,110
Еще одна информация, о которой я упоминал, является секретом клиента.

166
00:11:00,110 --> 00:11:03,855
Теперь, в потоке аутентификации, о котором я собираюсь поговорить,

167
00:11:03,855 --> 00:11:07,640
секрет клиента никогда никому не будет раскрыт.

168
00:11:07,640 --> 00:11:11,700
Секрет клиента будет находиться только на стороне сервера Express.

169
00:11:11,700 --> 00:11:15,335
Вернуться, когда сервер Express пытается аутентифицировать и

170
00:11:15,335 --> 00:11:20,600
получить доступ к профилю пользователя из Facebook,

171
00:11:20,600 --> 00:11:23,795
клиентское приложение, Express сервер

172
00:11:23,795 --> 00:11:27,490
отправит как идентификатор клиента, так и секрет клиента,

173
00:11:27,490 --> 00:11:32,555
вместе с токеном доступа, который пользователь передает ему в Facebook.

174
00:11:32,555 --> 00:11:34,988
И Facebook, в свою очередь,

175
00:11:34,988 --> 00:11:38,945
разрешает своему клиентскому приложению доступ к

176
00:11:38,945 --> 00:11:43,935
серверу ресурсов для получения данных профиля пользователя.

177
00:11:43,935 --> 00:11:50,390
И как только данные профиля пользователя будут получены с сервера ресурсов Facebook,

178
00:11:50,390 --> 00:11:54,530
то мой Express сервер собирается создать учетную запись

179
00:11:54,530 --> 00:11:59,383
для этого конкретного пользователя, который зарегистрировал их со своей учетной записью Facebook.

180
00:11:59,383 --> 00:12:05,995
А затем, впоследствии, предоставить пользователю веб-токен JSON,

181
00:12:05,995 --> 00:12:09,190
который пользователь может затем использовать для доступа

182
00:12:09,190 --> 00:12:12,530
к ресурсам, хранящимся на сервере Express.

183
00:12:12,530 --> 00:12:15,040
Итак, опять же, чтобы обобщить это,

184
00:12:15,040 --> 00:12:20,387
у меня есть диаграмма, чтобы объяснить вам это немного более подробно.

185
00:12:20,387 --> 00:12:22,000
В дополнение к этому,

186
00:12:22,000 --> 00:12:24,225
есть также токен обновления.

187
00:12:24,225 --> 00:12:29,910
Когда токен доступа выдается сервером Facebook OAuth 2,

188
00:12:29,910 --> 00:12:31,875
токен доступа имеет ограниченный срок службы.

189
00:12:31,875 --> 00:12:34,750
После этого токен доступа станет недействительным.

190
00:12:34,750 --> 00:12:39,203
Таким образом, токен доступа должен быть сохранен конфиденциальным.

191
00:12:39,203 --> 00:12:43,285
Таким образом, весь этот обмен токенами между различными сайтами

192
00:12:43,285 --> 00:12:48,040
будет осуществляться в зашифрованном материале с использованием протокола HTTPS.

193
00:12:48,040 --> 00:12:50,980
Поэтому убедитесь, что когда вы отправляете свой токен доступа из

194
00:12:50,980 --> 00:12:56,838
вашего пользовательского интерфейса на сервер Express,

195
00:12:56,838 --> 00:13:02,146
вы будете отправлять токен доступа только через HTTPS, а не HTTP.

196
00:13:02,146 --> 00:13:04,930
Это очень важно, потому что вы не

197
00:13:04,930 --> 00:13:08,110
хотите, чтобы ваш токен доступа был раскрыт никому, потому что любой,

198
00:13:08,110 --> 00:13:10,960
кто может получить один из ваших токенов доступа, может притвориться

199
00:13:10,960 --> 00:13:15,130
своим клиентским приложением, а затем получить доступ к вашему профилю пользователя.

200
00:13:15,130 --> 00:13:16,820
Так что это очень важно.

201
00:13:16,820 --> 00:13:20,005
Теперь, поскольку токен доступа имеет ограниченное время жизни,

202
00:13:20,005 --> 00:13:22,495
существует также соответствующий токен обновления,

203
00:13:22,495 --> 00:13:27,550
который можно использовать для обновления токена доступа с истекшим сроком службы.

204
00:13:27,550 --> 00:13:30,790
Теперь, в виде потока, который мы собираемся

205
00:13:30,790 --> 00:13:35,500
использовать с нашим приложением в упражнении,

206
00:13:35,500 --> 00:13:38,285
мы не сможем использовать токен обновления.

207
00:13:38,285 --> 00:13:41,620
Каждый раз, когда пользователь захочет разрешить

208
00:13:41,620 --> 00:13:46,070
серверу Express перейти и получить информацию профиля из Facebook,

209
00:13:46,070 --> 00:13:48,470
пользователю придется явно предоставить

210
00:13:48,470 --> 00:13:52,736
новый токен доступа, полученный из Facebook.

211
00:13:52,736 --> 00:13:56,665
Одна часть, которую я только что упомянул кратко,

212
00:13:56,665 --> 00:13:58,221
но я не разработал,

213
00:13:58,221 --> 00:14:01,920
заключается в том, как клиентское приложение, сервер Express,

214
00:14:01,920 --> 00:14:07,260
масштабируется, как он регистрируется в поставщике услуг OAuth 2?

215
00:14:07,260 --> 00:14:11,440
Теперь, здесь многие из поставщиков услуг OAuth 2

216
00:14:11,440 --> 00:14:16,705
предоставляют способ регистрации приложения на своем сайте.

217
00:14:16,705 --> 00:14:18,050
Таким образом, клиентское приложение,

218
00:14:18,050 --> 00:14:20,485
экспресс-серверы в нашем примере,

219
00:14:20,485 --> 00:14:25,875
будет регистрироваться как клиентское приложение на поставщике услуг OAuth.

220
00:14:25,875 --> 00:14:27,460
Таким образом, как вы увидите в упражнении,

221
00:14:27,460 --> 00:14:31,795
самый первый шаг, который мы сделаем, это войти в Facebook с

222
00:14:31,795 --> 00:14:37,795
нашей учетной записью, а затем создать приложение на сайте Facebook.

223
00:14:37,795 --> 00:14:44,020
Когда вы это сделаете, Facebook выдаст вам идентификатор клиентского приложения и секрет клиента.

224
00:14:44,020 --> 00:14:47,830
Эта процедура применяется ко многим другим поставщикам услуг OAuth, поскольку

225
00:14:47,830 --> 00:14:51,960
это общий поток, о котором говорит протокол OAuth 2.

226
00:14:51,960 --> 00:14:57,130
Таким образом, идентификатор клиентского приложения и секрет клиента полезны для нас,

227
00:14:57,130 --> 00:15:02,320
чтобы иметь возможность доказать нашу личность

228
00:15:02,320 --> 00:15:08,960
серверу OAuth, когда мы передаем токен доступа, который мы получаем от пользователя.

229
00:15:08,960 --> 00:15:11,500
Теперь есть также URL-адрес перенаправления, который вам нужно

230
00:15:11,500 --> 00:15:14,650
зарегистрировать при регистрации клиентского приложения,

231
00:15:14,650 --> 00:15:18,520
и вы увидите, что я выполняю это в шагах, которые я регистрирую

232
00:15:18,520 --> 00:15:23,410
приложение на сайте Facebook.

233
00:15:23,410 --> 00:15:26,380
Итак, подытоживая информационный поток

234
00:15:26,380 --> 00:15:29,765
, о котором мы только что кратко говорили в предыдущем случае,

235
00:15:29,765 --> 00:15:31,855
позвольте мне начать с этого момента.

236
00:15:31,855 --> 00:15:35,295
Первый момент, на который нужно обратить внимание, это владелец ресурса.

237
00:15:35,295 --> 00:15:39,355
Таким образом, владельцем ресурса является пользователь, который

238
00:15:39,355 --> 00:15:43,660
собирается использовать свою учетную запись в социальных сетях.

239
00:15:43,660 --> 00:15:45,625
Facebook, в этом примере,

240
00:15:45,625 --> 00:15:49,490
имеет аутентификацию для пользователя.

241
00:15:49,490 --> 00:15:54,515
Таким образом, владелец ресурса - это тот, который имеет профиль о ресурсе.

242
00:15:54,515 --> 00:15:57,760
И эта информация профиля для каждой учетной записи Facebook,

243
00:15:57,760 --> 00:16:00,535
они хранились на сервере Facebook.

244
00:16:00,535 --> 00:16:05,067
Таким образом, сервер Facebook предоставляет сервер ресурсов здесь.

245
00:16:05,067 --> 00:16:08,410
Так что это поставщик услуг OAuth, который вы видите

246
00:16:08,410 --> 00:16:12,691
в правой части этой картины здесь.

247
00:16:12,691 --> 00:16:17,320
Представьте себе сервер Facebook с правой стороны, это клиентское приложение,

248
00:16:17,320 --> 00:16:18,928
которое имеет оставшийся сервер API,

249
00:16:18,928 --> 00:16:20,477
экспресс-сервер, который мы реализовали,

250
00:16:20,477 --> 00:16:22,270
в этом случае является клиентским приложением,

251
00:16:22,270 --> 00:16:24,700
а владельцем ресурса является пользователь.

252
00:16:24,700 --> 00:16:28,780
URL переднего плана пользователя, который собирается

253
00:16:28,780 --> 00:16:33,510
разрешить вам перейти в Facebook, чтобы проверить учетные данные этого пользователя.

254
00:16:33,510 --> 00:16:39,245
Поэтому, когда вы хотите получить доступ к информации на стороне клиента,

255
00:16:39,245 --> 00:16:44,355
вам сначала придется пойти и

256
00:16:44,355 --> 00:16:47,730
авторизовать это клиентское приложение,

257
00:16:47,730 --> 00:16:51,673
чтобы иметь возможность получить доступ к информации вашего профиля.

258
00:16:51,673 --> 00:16:52,855
Таким образом, клиентское приложение,

259
00:16:52,855 --> 00:16:55,120
если оно действует как веб-приложение,

260
00:16:55,120 --> 00:17:00,095
оно предоставит соответствующую кнопку там, говоря войти в систему с помощью Facebook.

261
00:17:00,095 --> 00:17:01,740
И поэтому, когда вы нажимаете на кнопку

262
00:17:01,740 --> 00:17:04,780
, по сути, начинается первый шаг.

263
00:17:04,780 --> 00:17:07,375
Запрос авторизации пользователя инициирован.

264
00:17:07,375 --> 00:17:09,270
Таким образом, ваше клиентское приложение

265
00:17:09,270 --> 00:17:10,910
, через

266
00:17:10,910 --> 00:17:17,409
агент пользователя, в основном клиентское приложение, клиентское приложение.

267
00:17:17,409 --> 00:17:22,725
Это может быть приложение Angular, которое мы разработали, или

268
00:17:22,725 --> 00:17:25,950
это мобильное приложение, будь то Ionic или это

269
00:17:25,950 --> 00:17:30,120
приложение NativeScript, которое мы разработали на курсах ранее в

270
00:17:30,120 --> 00:17:37,807
специализации или даже собственное приложение, например приложение для iOS или приложение для Android.

271
00:17:37,807 --> 00:17:39,060
Все они действуют в качестве агента пользователя.

272
00:17:39,060 --> 00:17:42,360
Таким

273
00:17:42,360 --> 00:17:45,420
образом, пользовательский агент использует процесс запроса авторизации через

274
00:17:45,420 --> 00:17:48,360
пользовательский агент на сервер авторизации,

275
00:17:48,360 --> 00:17:50,500
который является сервером Facebook.

276
00:17:50,500 --> 00:17:52,235
Теперь, когда это будет передано,

277
00:17:52,235 --> 00:17:55,796
тогда владелец ресурса или пользователь,

278
00:17:55,796 --> 00:18:01,065
который пытается предоставить доступ к своему профилю для этого клиентского приложения,

279
00:18:01,065 --> 00:18:03,690
должен будет разрешить Facebook, чтобы иметь

280
00:18:03,690 --> 00:18:06,600
возможность делиться этой информацией с клиентским приложением.

281
00:18:06,600 --> 00:18:11,250
В неявном подходе гранта потока, который мы используем в

282
00:18:11,250 --> 00:18:16,025
нашем примере здесь, а также в следующем упражнении,

283
00:18:16,025 --> 00:18:18,390
неявный подход гранта потока является

284
00:18:18,390 --> 00:18:22,875
наиболее подходящим подходом, когда вы реализуете веб-приложение с использованием

285
00:18:22,875 --> 00:18:26,563
фреймворка, такого как Angular или гибридное мобильное приложение

286
00:18:26,563 --> 00:18:30,925
с Ionic или NativeScript или даже собственное приложение.

287
00:18:30,925 --> 00:18:34,320
Подход неявного гранта потока является гораздо более простым способом

288
00:18:34,320 --> 00:18:39,170
работы OAuth 2 для таких приложений.

289
00:18:39,170 --> 00:18:43,930
Таким образом, владелец ресурса нажимает на кнопку входа,

290
00:18:43,930 --> 00:18:49,710
затем сервер авторизации предложит владельцу ресурса информацию, говорящую:

291
00:18:49,710 --> 00:18:54,330
«Это клиентское приложение хочет получить доступ к информации вашего профиля.

292
00:18:54,330 --> 00:18:55,725
Вы разрешаете это?»

293
00:18:55,725 --> 00:18:58,965
И так это будет всплывать Facebook,

294
00:18:58,965 --> 00:19:01,860
а затем вы нажмете на кнопку, говорящую: «Да,

295
00:19:01,860 --> 00:19:05,278
я разрешаю этому клиентскому приложению получить доступ от моего имени».

296
00:19:05,278 --> 00:19:06,645
Таким образом, на этом этапе

297
00:19:06,645 --> 00:19:08,680
сервер авторизации на Facebook,

298
00:19:08,680 --> 00:19:11,190
сервер авторизации OAuth 2 на Facebook,

299
00:19:11,190 --> 00:19:13,380
будет генерировать токен доступа.

300
00:19:13,380 --> 00:19:15,105
Чтобы сгенерировать этот токен доступа,

301
00:19:15,105 --> 00:19:20,405
он будет использовать идентификатор клиента для этого клиентского приложения, приложение

302
00:19:20,405 --> 00:19:22,535
Express сервера, которое мы регистрируем.

303
00:19:22,535 --> 00:19:28,165
Таким образом, идентификатор клиента должен быть частью пользовательского агента, который использует этот пользователь.

304
00:19:28,165 --> 00:19:33,093
Таким образом, этот идентификатор клиента будет встроен в приложение Angular, приложение

305
00:19:33,093 --> 00:19:38,585
Ionic или приложение NativeScript или даже приложение iOS или Android.

306
00:19:38,585 --> 00:19:40,560
Таким образом, идентификатор клиента будет использоваться

307
00:19:40,560 --> 00:19:43,410
пользовательским агентом для поворота сервера авторизации, говорящего:

308
00:19:43,410 --> 00:19:48,108
«Это клиентское приложение хочет получить доступ к моему профилю,

309
00:19:48,108 --> 00:19:52,704
и я готов разрешить вам доступ к профилю».

310
00:19:52,704 --> 00:19:53,760
Таким образом, в этот момент

311
00:19:53,760 --> 00:19:59,290
сервер авторизации отправит маркер доступа агенту пользователя в этом случае.

312
00:19:59,290 --> 00:20:02,670
Итак, помните, этот токен доступа приходит в пользовательский агент,

313
00:20:02,670 --> 00:20:09,180
который является мобильным приложением или их угловым приложением, которое реализуется нами.

314
00:20:09,180 --> 00:20:12,870
Затем этот пользовательский агент возьмет этот токен доступа, а

315
00:20:12,870 --> 00:20:18,479
затем передаст этот токен доступа этому клиентскому приложению.

316
00:20:18,479 --> 00:20:20,310
Таким образом, OAuth для входа в систему,

317
00:20:20,310 --> 00:20:23,305
но токен доступа будет передан клиентскому приложению,

318
00:20:23,305 --> 00:20:25,200
в этом случае экспресс-серверу,

319
00:20:25,200 --> 00:20:32,340
на определенном маршруте на маршрутизаторе пользователя,

320
00:20:32,340 --> 00:20:37,465
маршруте аутентификации на сайте клиентского приложения.

321
00:20:37,465 --> 00:20:41,000
Теперь, ранее, мы видели использование локальной аутентификации,

322
00:20:41,000 --> 00:20:45,985
где мы отправили запрос на косую черту пользователя войти в систему.

323
00:20:45,985 --> 00:20:48,250
Теперь, чтобы это работало в нашем приложении,

324
00:20:48,250 --> 00:20:50,580
мы настроим еще один на пользователей косой черты,

325
00:20:50,580 --> 00:20:54,095
косой черты Facebook, токен косой черты и так далее.

326
00:20:54,095 --> 00:21:02,500
Таким образом, еще один URL-адрес, на котором мы предоставляем этот токен доступа к серверу Express.

327
00:21:02,500 --> 00:21:06,280
Теперь, когда этот токен доступа будет получен экспресс-сервером,

328
00:21:06,280 --> 00:21:09,630
экспресс-сервер возьмет этот токен доступа,

329
00:21:09,630 --> 00:21:14,240
а затем вместе со своим идентификатором клиента и секретом клиента,

330
00:21:14,240 --> 00:21:20,200
он отправит эту информацию на сервер авторизации.

331
00:21:20,200 --> 00:21:25,140
Затем сервер авторизации позволит своему клиентскому приложению получить

332
00:21:25,140 --> 00:21:30,565
доступ к серверу ресурсов, чтобы получить информацию о профиле.

333
00:21:30,565 --> 00:21:35,060
Таким образом, информация о профиле будет отправлена обратно в шестом шаге,

334
00:21:35,060 --> 00:21:37,890
в этом случае обратно в клиентское приложение.

335
00:21:37,890 --> 00:21:42,015
Поэтому, когда клиентское приложение получает информацию о профиле для пользователя,

336
00:21:42,015 --> 00:21:46,380
клиентское приложение создаст новую учетную запись для

337
00:21:46,380 --> 00:21:51,785
пользователя на каждом сайте, если учетная запись не существует.

338
00:21:51,785 --> 00:21:56,090
Если этот пользователь уже вошел в систему ранее, используя свой идентификатор Facebook,

339
00:21:56,090 --> 00:22:00,045
учетная запись уже будет существовать, чтобы клиентское приложение и сервер API Rest

340
00:22:00,045 --> 00:22:05,485
просто проверили, что эта учетная запись уже существует.

341
00:22:05,485 --> 00:22:06,865
И, в этот момент,

342
00:22:06,865 --> 00:22:12,550
пользователь проходит аутентификацию для стороннего входа в систему,

343
00:22:12,550 --> 00:22:18,321
предоставляемую сервисом аутентификации OAuth 2 Facebook.

344
00:22:18,321 --> 00:22:23,275
В этот момент клиентское приложение будет генерировать JSON Web Token,

345
00:22:23,275 --> 00:22:26,010
в примере, который мы будем реализовывать и осуществлять,

346
00:22:26,010 --> 00:22:33,040
а затем передать этот JSON Web Token обратно пользовательскому агенту или интерфейсному приложению,

347
00:22:33,040 --> 00:22:35,845
или угловому приложению, или приложению Ionic,

348
00:22:35,845 --> 00:22:38,590
или приложению NativeScript.

349
00:22:38,590 --> 00:22:45,160
Затем JSON Web Token будет впоследствии использоваться пользователем

350
00:22:45,160 --> 00:22:48,790
для аутентификации себя всякий раз, когда он или она хочет

351
00:22:48,790 --> 00:22:53,145
получить доступ к любым ресурсам, хранящимся на сервере Express.

352
00:22:53,145 --> 00:22:55,505
Итак, как только вы получите JSON Web Token,

353
00:22:55,505 --> 00:23:00,975
все последующие операции, вы уже видели, как это сделать с помощью JSON Web Token.

354
00:23:00,975 --> 00:23:03,565
Таким образом, как только вы получите JSON Web Token

355
00:23:03,565 --> 00:23:05,070
, ваша работа выполнена,

356
00:23:05,070 --> 00:23:10,150
и затем вы можете продолжить нормальную работу с этой точки.

357
00:23:10,150 --> 00:23:12,940
Теперь, когда истекает срок действия JSON Web

358
00:23:12,940 --> 00:23:17,618
Token, вы должны пройти весь процесс повторной аутентификации себя и,

359
00:23:17,618 --> 00:23:22,990
впоследствии, разрешить пользователям доступ к информации на вашем сайте.

360
00:23:22,990 --> 00:23:29,710
Итак, с этим быстрым пониманием того, как работают операции OAuth 2

361
00:23:29,710 --> 00:23:33,385
, опять же, как вы видите, здесь много деталей.

362
00:23:33,385 --> 00:23:38,950
Но, к счастью, нам не нужно иметь дело со всеми этими деталями, потому что мы будем

363
00:23:38,950 --> 00:23:46,285
использовать модуль узла, который заботится о большей части этих деталей от нашего имени.

364
00:23:46,285 --> 00:23:52,195
Так как мы уже настроили наш Express сервер для использования Passport,

365
00:23:52,195 --> 00:24:00,980
теперь мы можем использовать другой код модуля узла в качестве модуля Passport-Facebook-Token.

366
00:24:00,980 --> 00:24:04,595
Модуль Passport-Facebook-Token по существу реализует

367
00:24:04,595 --> 00:24:08,580
неявный подход к гранту, о котором я говорил ранее.

368
00:24:08,580 --> 00:24:11,320
Затем вы можете инициализировать

369
00:24:11,320 --> 00:24:18,160
новую стратегию в вашей стратегии Passport в вашем приложении. Кроме

370
00:24:18,160 --> 00:24:22,720
того, модуль Passport-Facebook-Token позволяет настроить

371
00:24:22,720 --> 00:24:31,090
новую стратегию аутентификации Passport для использования API OAuth 2 на основе Facebook.

372
00:24:31,090 --> 00:24:36,085
И поэтому, чтобы использовать этот модуль,

373
00:24:36,085 --> 00:24:41,615
вы устанавливаете это, сказав прошлый npm install pasport- facebook-token

374
00:24:41,615 --> 00:24:44,980
, минус save, а

375
00:24:44,980 --> 00:24:51,010
затем, как только вы установили это, то вы настроете стратегию Facebook в своем приложении, и, после этого,

376
00:24:51,010 --> 00:24:57,810
используйте это для настройки стратегии для вашего Passport,

377
00:24:57,810 --> 00:25:04,990
чтобы использовать, если мы используем аутентификацию на основе OAuth 2 для нашего приложения.

378
00:25:04,990 --> 00:25:09,270
С этим быстрым пониманием OAuth 2,

379
00:25:09,270 --> 00:25:11,770
давайте

380
00:25:11,770 --> 00:25:16,630
перейдем к упражнению, где мы настроим наш Express сервер, чтобы действительно использовать

381
00:25:16,630 --> 00:25:20,920
этот неявный грант подход, чтобы позволить нам

382
00:25:20,920 --> 00:25:25,450
проверить нашу личность на сервере Express и,

383
00:25:25,450 --> 00:25:29,745
после этого, получить доступ к ресурсам, блюдам,

384
00:25:29,745 --> 00:25:38,180
рекламные акции и информацию лидеров, хранящуюся на нашем сервере Express.