1
00:00:00,000 --> 00:00:04,869
[МУЗЫКА]

2
00:00:04,869 --> 00:00:06,266
В предыдущих уроках

3
00:00:06,266 --> 00:00:10,110
мы видели несколько различных типов схем аутентификации.

4
00:00:10,110 --> 00:00:14,910
Мы начали с обычной аутентификации, затем мы посмотрели, как мы можем использовать файлы cookie для

5
00:00:14,910 --> 00:00:18,290
аутентификации и даже подписанные файлы cookie, а

6
00:00:18,290 --> 00:00:22,090
затем мы рассмотрели аутентификацию на основе сеанса.

7
00:00:22,090 --> 00:00:27,070
Где сервер отслеживает информацию о каждом клиенте, а

8
00:00:27,070 --> 00:00:30,680
затем cookie будет использоваться как способ индексирования в серверную

9
00:00:30,680 --> 00:00:35,720
базу данных для извлечения дополнительной информации, для проверки пользователя.

10
00:00:35,720 --> 00:00:41,160
Теперь файлы cookie и сеансовые проверки подлинности не масштабируются,

11
00:00:41,160 --> 00:00:47,300
потому что сервер должен отслеживать всех разных пользователей.

12
00:00:48,820 --> 00:00:53,120
Несмотря на то, что это делается вне самого протокола HTTP, но

13
00:00:53,120 --> 00:00:56,160
все же тот факт, что вам нужно отслеживать

14
00:00:56,160 --> 00:01:00,660
всю информацию раздела сайта сервера, делает его не очень масштабируемым.

15
00:01:00,660 --> 00:01:04,510
Таким образом, здесь аутентификация на основе токенов

16
00:01:04,510 --> 00:01:06,570
оказалась очень полезной.

17
00:01:06,570 --> 00:01:11,260
мы рассмотрим аутентификацию на базе токенов немного более подробно в этой лекции и

18
00:01:11,260 --> 00:01:12,830
упражнении, которое следует за этим.

19
00:01:14,680 --> 00:01:18,880
Опять же, быстро просматривая файлы cookie и аутентификацию на основе сеанса.

20
00:01:18,880 --> 00:01:20,580
При аутентификации на основе файлов cookie

21
00:01:20,580 --> 00:01:25,240
мы замечаем, что файлы cookie хранятся на стороне клиента, а файлы cookie включаются

22
00:01:25,240 --> 00:01:29,510
в каждое исходящее сообщение запроса, в результате чего сервер получает напоминание об

23
00:01:29,510 --> 00:01:35,050
этом конкретном клиенте, извлекая информацию из файла cookie.

24
00:01:35,050 --> 00:01:40,550
Cookie можно использовать вместе с сеансами, в результате чего файлы cookie сохраняют идентификатор сеанса,

25
00:01:40,550 --> 00:01:44,650
а затем, когда сервер получает входящий запрос от файла cookie,

26
00:01:44,650 --> 00:01:49,770
он извлекает идентификатор сеанса и использует его в качестве индекса в

27
00:01:49,770 --> 00:01:55,210
хранилище сеансов на стороне сервера для получения информации о сеансе конкретного клиента.

28
00:01:55,210 --> 00:01:56,840
Теперь, этот подход, как я уже сказал,

29
00:01:56,840 --> 00:02:01,234
не очень масштабируемый, потому что если у вас есть тысячи сеансов, сервер должен

30
00:02:01,234 --> 00:02:04,980
отслеживать все эти тысячи сеансов на стороне сервера.

31
00:02:04,980 --> 00:02:10,820
Несмотря на то, что это делается независимо от HTTP в хранилище,

32
00:02:10,820 --> 00:02:13,770
либо в хранилище файлов, либо в базе данных.

33
00:02:13,770 --> 00:02:14,610
Но все же

34
00:02:14,610 --> 00:02:19,520
тот факт, что вам нужно отслеживать всю эту информацию, делает ее немасштабируемой.

35
00:02:19,520 --> 00:02:23,960
Итак, опять же, чтобы напомнить вам еще раз,

36
00:02:23,960 --> 00:02:27,201
почему мы говорим об аутентификации на основе токенов?

37
00:02:27,201 --> 00:02:32,260
Сеансионная аутентификация, как мы уже видели ранее, отлично работает для

38
00:02:32,260 --> 00:02:39,910
веб-приложений и может легко позаботиться о аутентификации пользователей.

39
00:02:39,910 --> 00:02:43,660
Но затем аутентификация на основе сеанса, хотя это принцип

40
00:02:43,660 --> 00:02:48,280
серверов без гражданства, а также приводит к проблемам масштабируемости.

41
00:02:48,280 --> 00:02:52,727
Вторая проблема заключается в том, что мобильные приложения не

42
00:02:52,727 --> 00:02:58,090
очень хорошо обрабатывают сеансовую аутентификацию.

43
00:02:58,090 --> 00:03:01,742
Аналогичным образом, мобильные приложения испытывают трудности, связанные с файлами cookie.

44
00:03:01,742 --> 00:03:08,048
Итак, в таких условиях, когда ваш сервер обслуживает данные

45
00:03:08,048 --> 00:03:13,610
как для веб-приложения, так и для мобильного приложения.

46
00:03:13,610 --> 00:03:19,275
Затем аутентификация на основе сеанса не будет очень полезной, и

47
00:03:19,275 --> 00:03:25,139
именно здесь аутентификация на основе токенов становится намного более простой в использовании.

48
00:03:25,139 --> 00:03:29,369
В аутентификации на основе токенов в качестве имени

49
00:03:29,369 --> 00:03:34,589
на месте сервер выдает токен проверенному пользователю, и все последующие

50
00:03:34,589 --> 00:03:40,803
запросы, поступающие со стороны клиента, будут нести токен в самом запросе.

51
00:03:40,803 --> 00:03:48,992
Либо в виде заголовка запроса, либо в теле сообщения запроса.

52
00:03:48,992 --> 00:03:53,410
Кроме того, аутентификация на основе токенов также помогает нам

53
00:03:53,410 --> 00:03:57,965
справиться с так называемыми проблемами CORS или CSRF.

54
00:03:57,965 --> 00:04:00,480
Проблемы с распределением ресурсов между происхождением и так

55
00:04:00,480 --> 00:04:04,360
далее, я кратко расскажу о стоимости в следующем модуле.

56
00:04:04,360 --> 00:04:07,540
Но на данный момент аутентификация на основе токенов решает некоторые проблемы

57
00:04:07,540 --> 00:04:13,430
, связанные с автомобилями и проблемами, связанными с подделкой межсайтовых запросов.

58
00:04:13,430 --> 00:04:17,680
Мало того, что аутентификация на основе токенов намного проще для

59
00:04:17,680 --> 00:04:21,700
одного приложения, чтобы поделиться своей аутентификацией с другим приложением.

60
00:04:21,700 --> 00:04:24,610
Конечно, все это делается безопасным образом.

61
00:04:24,610 --> 00:04:28,867
Но, с аутентификацией на основе сеанса, это не просто.

62
00:04:28,867 --> 00:04:32,272
Как работает аутентификация на основе токенов?

63
00:04:32,272 --> 00:04:34,260
При аутентификации на основе токенов

64
00:04:34,260 --> 00:04:40,020
пользователь сначала должен проверить себя на стороне сервера.

65
00:04:40,020 --> 00:04:44,040
Теперь эта проверка может принимать формы, которые мы видели ранее.

66
00:04:44,040 --> 00:04:48,519
Таким образом, мы можем использовать локальную проверку, используя имя пользователя и пароль.

67
00:04:48,519 --> 00:04:53,111
Или мы можем даже использовать проверку третьей стороны, используя

68
00:04:53,111 --> 00:04:58,267
такие технологии, как oauth или oauth 2.0 или open ID.

69
00:04:58,267 --> 00:05:03,700
Мы кратко поговорим о oauth и oauth 2.0 в следующем модуле.

70
00:05:03,700 --> 00:05:08,790
Но, независимо от того, каким образом пользователь аутентифицируется,

71
00:05:08,790 --> 00:05:14,370
после того, как пользователь аутентифицирован, ваш сервер может просто выдать токен пользователю.

72
00:05:14,370 --> 00:05:18,790
И все последующие связи между пользователем и

73
00:05:18,790 --> 00:05:23,658
сервером, можно сделать просто с помощью этого токена.

74
00:05:23,658 --> 00:05:29,240
JSON Web Token, о котором мы будем говорить, является одной из таких

75
00:05:29,240 --> 00:05:35,465
схем аутентификации на основе токенов, и там сервер, когда он создает этот токен, он создаст подписанный токен.

76
00:05:35,465 --> 00:05:40,315
Использование секрета на сайте сервера, который знает только сервер.

77
00:05:40,315 --> 00:05:43,965
Таким образом, даже если третья сторона в сторону и между и

78
00:05:43,965 --> 00:05:49,185
пытается манипулировать токеном, даже если он захватывает токен и

79
00:05:49,185 --> 00:05:53,045
пытается манипулировать токеном, токен станет недействительным.

80
00:05:53,045 --> 00:05:57,201
И поэтому, такой способ защиты пользователя

81
00:05:57,201 --> 00:06:02,250
легко осуществим, все последующие запросы

82
00:06:02,250 --> 00:06:07,430
со стороны клиента должны нести токен в запросе,

83
00:06:07,430 --> 00:06:11,870
либо, как я уже сказал, в заголовке или в теле сообщения запроса.

84
00:06:11,870 --> 00:06:16,120
Поэтому, когда сервер получает этот токен, сервер проверит токен,

85
00:06:16,120 --> 00:06:20,810
чтобы убедиться, что это действительный токен, а затем, если он является допустимым токеном,

86
00:06:20,810 --> 00:06:25,430
сервер ответит на входящий запрос.

87
00:06:25,430 --> 00:06:31,210
Как я уже упоминал, JSON Web Tokens является одной из таких схем аутентификации на основе токенов.

88
00:06:31,210 --> 00:06:35,838
JSON Web Token - это очень простой способ кодирования

89
00:06:35,838 --> 00:06:41,174
информации в токене, а затем передать его на сайт клиента.

90
00:06:41,174 --> 00:06:45,702
Сам JSON Web Token основан на стандартах,

91
00:06:45,702 --> 00:06:49,670
это основано на IETF RFC 7519.

92
00:06:49,670 --> 00:06:53,499
IETF здесь, выступает за Инженерную группу Интернета.

93
00:06:53,499 --> 00:07:00,011
Организация, которая поручает все о том, как работает Интернет,

94
00:07:00,011 --> 00:07:06,427
и имеет дело с протоколами и политиками, связанными с Интернетом.

95
00:07:06,427 --> 00:07:10,391
RFC означает документ о стандартах,

96
00:07:10,391 --> 00:07:15,270
в терминах IETF RFC означает запрос на комментарии.

97
00:07:15,270 --> 00:07:18,650
И каждый такой нормативный документ несет в себе ряд.

98
00:07:18,650 --> 00:07:23,560
7519 в этом случае относится к документу,

99
00:07:23,560 --> 00:07:27,250
стандартному документу, связанному с JSON Web Token.

100
00:07:27,250 --> 00:07:31,420
Сам JSON Web Token является автономным токеном, он несет всю

101
00:07:31,420 --> 00:07:37,250
информацию внутри себя, что необходимо для идентификации пользователя.

102
00:07:37,250 --> 00:07:43,080
Мало того, что JSON Web Token можно разделить между двумя приложениями.

103
00:07:43,080 --> 00:07:46,930
Так, например, одно приложение, когда оно аутентифицируется, а затем получает

104
00:07:46,930 --> 00:07:51,760
JSON Web Token, может передать этот JSON Web Token и в этом приложении,

105
00:07:51,760 --> 00:07:56,950
что оно готово разрешить доступ к серверу от его имени.

106
00:07:56,950 --> 00:08:00,200
Этот обмен токеном делается очень безопасным образом,

107
00:08:00,200 --> 00:08:03,460
поэтому не беспокойтесь слишком много о безопасности там.

108
00:08:03,460 --> 00:08:04,990
Это не безопасно,

109
00:08:04,990 --> 00:08:09,090
где путем совместного использования токена между одним приложением другому.

110
00:08:09,090 --> 00:08:13,250
Таким образом, авторизация передается второму приложению, а

111
00:08:13,250 --> 00:08:17,740
второе приложение может авторизоваться от имени первого приложения

112
00:08:17,740 --> 00:08:18,990
для связи с сервером.

113
00:08:20,200 --> 00:08:24,200
Это возможно с токенами.

114
00:08:24,200 --> 00:08:28,710
Теперь, конечно, инженер в вас, очевидно, будет интересно, что именно находится

115
00:08:28,710 --> 00:08:32,690
внутри JSON Web Token, и как это полезно?

116
00:08:32,690 --> 00:08:39,120
JSON Web Token, как я уже сказал, кодируется в длинную строку, и

117
00:08:39,120 --> 00:08:43,530
сама эта строка может быть интерпретирована как состоящая из трех частей.

118
00:08:43,530 --> 00:08:49,470
Сама строка может, или сама закодированная строка содержит три части:

119
00:08:49,470 --> 00:08:52,896
Заголовок, Полезная нагрузка и Подпись.

120
00:08:52,896 --> 00:08:59,070
Это несет достаточно информации о том, как кодируется этот токен.

121
00:08:59,070 --> 00:09:03,780
Сам заголовок содержит конкретный алгоритм, который используется для

122
00:09:03,780 --> 00:09:08,460
кодирования этого JSON Web Token, и тип самого маркера.

123
00:09:08,460 --> 00:09:16,280
Алгоритм в этом случае будет HS256, который представляет собой 256-битную схему кодирования,

124
00:09:16,280 --> 00:09:21,140
которая используется для хеширования информации внутри токена.

125
00:09:21,140 --> 00:09:24,350
И в этом случае это JSON Web Token, и поэтому

126
00:09:24,350 --> 00:09:27,870
поле типа будет установлено в JWT.

127
00:09:27,870 --> 00:09:33,210
И так это информация, которая хранится в заголовке JSON Web Token. Сама

128
00:09:33,210 --> 00:09:38,800
полезная нагрузка, несет в себе информацию, которая поможет вам идентифицировать пользователя.

129
00:09:38,800 --> 00:09:41,440
В упражнении, которое мы сделаем,

130
00:09:41,440 --> 00:09:46,730
часовая полезная нагрузка несет только идентификатор пользователя внутри полезной нагрузки.

131
00:09:46,730 --> 00:09:48,720
Никакой другой информации не требуется.

132
00:09:48,720 --> 00:09:51,690
Этот идентификатор может быть использован на стороне сервера,

133
00:09:51,690 --> 00:09:58,350
чтобы индексировать в Mongo DB, чтобы получить полную информацию о пользователе, если это необходимо.

134
00:09:58,350 --> 00:10:02,050
Итак, вы увидите, что мы кодируем идентификатор, а

135
00:10:02,050 --> 00:10:05,020
затем сохраним его в полезной нагрузке этого сообщения.

136
00:10:05,020 --> 00:10:09,470
При необходимости можно хранить дополнительную информацию в полезной нагрузке сообщения.

137
00:10:09,470 --> 00:10:11,410
Но чем больше информации, которую вы сохранили там,

138
00:10:11,410 --> 00:10:15,720
тем больше соответствующий JSON Web Token будет мне.

139
00:10:15,720 --> 00:10:20,010
Таким образом, попробуйте ограничить объем информации, которую вы сохранили в полезной нагрузке

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

141
00:10:22,155 --> 00:10:27,545
Как мы увидим в упражнении, у нас есть модуль узла, который позволяет нам

142
00:10:27,545 --> 00:10:30,875
кодировать и создавать JSON Web Token,

143
00:10:30,875 --> 00:10:34,395
на основе информации, которую мы хотим поместить в полезную нагрузку.

144
00:10:34,395 --> 00:10:38,735
Теперь, когда вы создаете JSON Web Token, вы также предоставляете подпись.

145
00:10:38,735 --> 00:10:44,929
Секретный ключ на стороне сервера, который используется для кодирования этого JSON Web Token,

146
00:10:44,929 --> 00:10:51,044
и этот секрет также включен в подписную часть JSON Web Token.

147
00:10:51,044 --> 00:10:55,232
Сама подпись включена таким образом, что

148
00:10:55,232 --> 00:10:58,797
перед закодированным заголовком и полезной нагрузкой есть основы,

149
00:10:58,797 --> 00:11:04,750
которые затем кодируются с использованием конкретного секрета, который используется сервером.

150
00:11:04,750 --> 00:11:08,644
И это закодировано, как я сказал HMAC,

151
00:11:08,644 --> 00:11:14,144
что мы упоминали в одном из предыдущих уроков и

152
00:11:14,144 --> 00:11:20,922
используя 256-битное хэширование, и это включено в подпись.

153
00:11:20,922 --> 00:11:25,118
Итак, когда этот JSON Web Token получен на стороне сервера, и

154
00:11:25,118 --> 00:11:30,094
когда сервер декодирует этот токен, сервер может перекрестно проверить,

155
00:11:30,094 --> 00:11:34,525
чтобы убедиться, что этот JSON Web Token не был изменен кем-либо,

156
00:11:34,525 --> 00:11:39,460
в то время как токен передается между клиентом и сайтом сервера.

157
00:11:39,460 --> 00:11:43,020
Поэтому, если вы знаете что-нибудь о безопасности, злоумышленниках

158
00:11:43,020 --> 00:11:47,670
и так далее, вы понимаете, почему важно кодировать токен и

159
00:11:47,670 --> 00:11:53,250
проверить подлинность токена на сайте сервера.

160
00:11:53,250 --> 00:11:58,640
Как я уже упоминал, если вам нужно иметь дело с JSON Web Tokens в вашем приложении узла.

161
00:11:58,640 --> 00:12:02,810
Существует конкретный модуль узла, называемый как модуль узла jsonwebtoken.

162
00:12:02,810 --> 00:12:07,830
Этот модуль узла реализует стандарты, связанные с JSON Web Token, и

163
00:12:07,830 --> 00:12:10,640
он может быть включен в ваше приложение узла.

164
00:12:10,640 --> 00:12:15,190
Этот модуль сам предоставляет метод, называемый знаком, который позволяет подписывать и

165
00:12:15,190 --> 00:12:18,910
выдавать токен клиенту со стороны сервера.

166
00:12:18,910 --> 00:12:21,820
Он также содержит метод проверки.

167
00:12:21,820 --> 00:12:27,040
Который может быть использован для проверки подлинности или

168
00:12:27,040 --> 00:12:33,380
для обеспечения подлинности входящего JSON Web токена,

169
00:12:33,380 --> 00:12:38,620
поэтому мы будем использовать модуль JSON Web токена, в нашем упражнении.

170
00:12:38,620 --> 00:12:42,010
Вместе с модулем JSON Web Token

171
00:12:42,010 --> 00:12:47,450
мы также использовали модуль Passport-JWT, модуль узла.

172
00:12:47,450 --> 00:12:54,547
Что обеспечивает стратегии на основе jwt для нашего модуля аутентификации паспортов.

173
00:12:54,547 --> 00:12:59,441
Таким образом, это обеспечивает паспортную стратегию для аутентификации с помощью JSON Web Token.

174
00:12:59,441 --> 00:13:06,153
Таким образом, это позволяет вам аутентифицировать конечную точку RESTful, используя JWT в качестве

175
00:13:06,153 --> 00:13:12,240
метода для проверки, не требуя, чтобы сервер использовал сеансы.

176
00:13:12,240 --> 00:13:17,300
Теперь модуль паспорта JWT

177
00:13:17,300 --> 00:13:21,710
поддерживает метод даже извлечения токена JWT из

178
00:13:21,710 --> 00:13:26,970
входящего сообщения запроса, а затем даже проверки токена от вашего имени.

179
00:13:26,970 --> 00:13:31,470
Интерн модуля Passport-JWT, использует модуль JSON Web Token для

180
00:13:31,470 --> 00:13:34,550
проверки этого JSON Web Token.

181
00:13:34,550 --> 00:13:40,300
Сам токен может быть перенесен в заголовок входящего запроса,

182
00:13:40,300 --> 00:13:44,350
в заголовок, даже в заголовке аутентификации входящего запроса,

183
00:13:44,350 --> 00:13:46,940
что и будет делать в упражнении.

184
00:13:46,940 --> 00:13:51,420
Токен также может быть перенесен в тело входящего запроса, и в этом случае

185
00:13:51,420 --> 00:13:54,610
мы должны извлечь токен из тела входящего запроса, а

186
00:13:54,610 --> 00:13:56,352
затем использовать его.

187
00:13:56,352 --> 00:14:01,170
Модуль Passport-JWT поддерживает это также, если вы решите

188
00:14:01,170 --> 00:14:06,580
использовать его как способ передачи токена обратно от клиента на сайт сервера.

189
00:14:06,580 --> 00:14:11,600
JSON Web Token, также может быть включен в параметры запроса URL, если вы так

190
00:14:11,600 --> 00:14:16,440
решили, и может быть извлечен из него b Passport-JWT и

191
00:14:16,440 --> 00:14:18,370
использован для аутентификации.

192
00:14:18,370 --> 00:14:22,783
Теперь, с этим быстрым пониманием JSON Web Token и

193
00:14:22,783 --> 00:14:27,915
как они полезны, мы перейдем к упражнению, где мы будем использовать

194
00:14:27,915 --> 00:14:33,230
модуль Passport-JWT вместе с модулем JSON Web Token

195
00:14:33,230 --> 00:14:38,211
и настроить наш сервер Express Rest API для использования JSON Web Token.

196
00:14:38,211 --> 00:14:41,589
[ МУЗЫКА]