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

2
00:00:04,869 --> 00:00:06,266
Trong các bài học trước đây,

3
00:00:06,266 --> 00:00:10,110
chúng ta đã thấy một số loại khác nhau của các chương trình xác thực.

4
00:00:10,110 --> 00:00:14,910
Chúng tôi bắt đầu với xác thực cơ bản, sau đó chúng tôi xem xét cách chúng tôi có thể sử dụng cookie để

5
00:00:14,910 --> 00:00:18,290
thực hiện xác thực, và thậm chí cookie đã ký

6
00:00:18,290 --> 00:00:22,090
, và sau đó, chúng tôi xem xét xác thực dựa trên phiên.

7
00:00:22,090 --> 00:00:27,070
Nơi máy chủ đang theo dõi thông tin về mỗi khách hàng, và

8
00:00:27,070 --> 00:00:30,680
sau đó cookie sẽ được sử dụng như một cách để lập chỉ mục vào

9
00:00:30,680 --> 00:00:35,720
cơ sở dữ liệu phía máy chủ để trích xuất thông tin bổ sung, để xác nhận người dùng.

10
00:00:35,720 --> 00:00:41,160
Bây giờ, cookie và phiên dựa trên xác thực không có khả năng mở rộng,

11
00:00:41,160 --> 00:00:47,300
bởi vì có máy chủ cần theo dõi tất cả những người dùng khác nhau.

12
00:00:48,820 --> 00:00:53,120
Mặc dù, điều này được thực hiện bên ngoài giao thức HTTP, nhưng

13
00:00:53,120 --> 00:00:56,160
vẫn là thực tế là bạn cần theo dõi

14
00:00:56,160 --> 00:01:00,660
tất cả các thông tin phần của trang web máy chủ, làm cho nó không phải là rất khả năng mở rộng.

15
00:01:00,660 --> 00:01:04,510
Vì vậy, đây là nơi xác thực dựa trên Token đã

16
00:01:04,510 --> 00:01:06,570
được chứng minh là rất hữu ích.

17
00:01:06,570 --> 00:01:11,260
chúng ta sẽ xem xét xác thực token-base một chút chi tiết hơn trong bài giảng này và

18
00:01:11,260 --> 00:01:12,830
bài tập sau.

19
00:01:14,680 --> 00:01:18,880
Một lần nữa, nhanh chóng xem xét cookie và xác thực dựa trên phiên.

20
00:01:18,880 --> 00:01:20,580
Với việc xác thực dựa

21
00:01:20,580 --> 00:01:25,240
trên cookie, chúng tôi nhận thấy rằng cookie được lưu trữ ở phía khách hàng, và cookie được bao gồm

22
00:01:25,240 --> 00:01:29,510
trong mỗi thông báo yêu cầu gửi đi, theo đó, máy chủ được nhắc nhở về

23
00:01:29,510 --> 00:01:35,050
khách hàng cụ thể đó, bằng cách trích xuất thông tin từ cookie.

24
00:01:35,050 --> 00:01:40,550
Cookie có thể được sử dụng cùng với các phiên, theo đó các cookie lưu trữ ID phiên,

25
00:01:40,550 --> 00:01:44,650
và sau đó khi máy chủ nhận được yêu cầu đến từ cookie,

26
00:01:44,650 --> 00:01:49,770
nó chiết xuất ID phiên và sử dụng đó như là một chỉ mục vào

27
00:01:49,770 --> 00:01:55,210
cửa hàng phiên phía máy chủ để lấy thông tin phiên cho khách hàng cụ thể.

28
00:01:55,210 --> 00:01:56,840
Bây giờ, cách tiếp cận này như tôi đã nói,

29
00:01:56,840 --> 00:02:01,234
không phải là rất khả năng mở rộng bởi vì nếu bạn có hàng ngàn phiên, máy chủ cần

30
00:02:01,234 --> 00:02:04,980
theo dõi tất cả hàng ngàn phiên ở phía máy chủ.

31
00:02:04,980 --> 00:02:10,820
Mặc dù nó được thực hiện độc lập với HTTP trong một cửa hàng,

32
00:02:10,820 --> 00:02:13,770
hoặc là một tập tin lưu trữ hoặc một cơ sở dữ liệu.

33
00:02:13,770 --> 00:02:14,610
Tuy nhiên,

34
00:02:14,610 --> 00:02:19,520
thực tế là bạn cần phải theo dõi tất cả các thông tin này làm cho nó không thể mở rộng.

35
00:02:19,520 --> 00:02:23,960
Vì vậy, một lần nữa, để nhắc nhở bạn một lần nữa,

36
00:02:23,960 --> 00:02:27,201
tại sao chúng ta lại nói về chứng thực dựa trên token?

37
00:02:27,201 --> 00:02:32,260
Xác thực dựa trên phiên làm việc, như chúng ta đã thấy trước đó, hoạt động hoàn toàn tốt cho các

38
00:02:32,260 --> 00:02:39,910
ứng dụng web và có thể dễ dàng chăm sóc xác thực người dùng.

39
00:02:39,910 --> 00:02:43,660
Nhưng sau đó, xác thực dựa trên phiên, trong khi đó là nguyên tắc của các

40
00:02:43,660 --> 00:02:48,280
máy chủ không trạng thái và cũng dẫn đến các vấn đề về khả năng mở rộng.

41
00:02:48,280 --> 00:02:52,727
Vấn đề thứ hai là, các ứng dụng di động không

42
00:02:52,727 --> 00:02:58,090
xử lý xác thực dựa trên phiên rất tốt.

43
00:02:58,090 --> 00:03:01,742
Tương tự như vậy, các ứng dụng di động có một thời gian khó khăn đối phó với cookie.

44
00:03:01,742 --> 00:03:08,048
Vì vậy, trong những trường hợp như vậy mà máy chủ của bạn đang phục vụ dữ liệu cho

45
00:03:08,048 --> 00:03:13,610
cả một ứng dụng web, cũng như một ứng dụng di động.

46
00:03:13,610 --> 00:03:19,275
Sau đó, xác thực dựa trên phiên sẽ không được rất hữu ích, và

47
00:03:19,275 --> 00:03:25,139
đây là nơi xác thực dựa trên mã thông báo trở nên dễ sử dụng hơn rất nhiều.

48
00:03:25,139 --> 00:03:29,369
Trong một xác thực dựa trên

49
00:03:29,369 --> 00:03:34,589
Token như tên tại chỗ, máy chủ sẽ phát hành một mã thông báo cho một người dùng được xác nhận, và tất cả các

50
00:03:34,589 --> 00:03:40,803
yêu cầu tiếp theo đến từ phía khách hàng, sẽ chịu mã thông báo trong chính yêu cầu đó.

51
00:03:40,803 --> 00:03:48,992
Hoặc dưới dạng tiêu đề yêu cầu hoặc trong nội dung của thư yêu cầu.

52
00:03:48,992 --> 00:03:53,410
Hơn nữa, xác thực dựa trên token cũng giúp chúng tôi

53
00:03:53,410 --> 00:03:57,965
giải quyết những vấn đề được gọi là CORS hoặc CSRF.

54
00:03:57,965 --> 00:04:00,480
Các vấn đề chia sẻ tài nguyên chéo nguồn gốc và như vậy

55
00:04:00,480 --> 00:04:04,360
, tôi sẽ nói ngắn gọn về chi phí trong mô-đun tiếp theo.

56
00:04:04,360 --> 00:04:07,540
Nhưng cho thời điểm này, xác thực dựa trên Token giải quyết một số

57
00:04:07,540 --> 00:04:13,430
vấn đề nằm với xe hơi và các vấn đề liên quan đến giả mạo yêu cầu qua trang web.

58
00:04:13,430 --> 00:04:17,680
Không chỉ vậy, xác thực dựa trên Token là rất dễ dàng hơn cho

59
00:04:17,680 --> 00:04:21,700
một ứng dụng để chia sẻ xác thực của nó với một ứng dụng khác.

60
00:04:21,700 --> 00:04:24,610
Tất nhiên, điều này được thực hiện một cách an toàn.

61
00:04:24,610 --> 00:04:28,867
Nhưng, với xác thực dựa trên phiên, đó không phải là thẳng về phía trước.

62
00:04:28,867 --> 00:04:32,272
Xác thực dựa trên Token hoạt động như thế nào?

63
00:04:32,272 --> 00:04:34,260
Trong xác thực dựa trên Token,

64
00:04:34,260 --> 00:04:40,020
người dùng trước tiên cần phải xác thực bản thân mình ở phía máy chủ.

65
00:04:40,020 --> 00:04:44,040
Bây giờ, sự xác nhận này có thể đưa vào các hình thức mà chúng ta đã thấy trước đó.

66
00:04:44,040 --> 00:04:48,519
Vì vậy, chúng tôi có thể sử dụng một xác nhận địa phương sử dụng tên người dùng và mật khẩu.

67
00:04:48,519 --> 00:04:53,111
Hoặc, chúng tôi thậm chí có thể sử dụng xác thực của bên thứ ba bằng cách sử dụng các

68
00:04:53,111 --> 00:04:58,267
công nghệ như, oauth hoặc oauth 2.0 hoặc mở ID.

69
00:04:58,267 --> 00:05:03,700
Chúng ta sẽ nói ngắn gọn về oauth và oauth 2.0 trong mô-đun tiếp theo.

70
00:05:03,700 --> 00:05:08,790
Tuy nhiên, bất kể cách nào người dùng xác thực, một khi người dùng

71
00:05:08,790 --> 00:05:14,370
được xác thực, ngay sau đó, máy chủ của bạn có thể chỉ đơn giản phát hành một mã thông báo cho người dùng.

72
00:05:14,370 --> 00:05:18,790
Và tất cả các giao tiếp tiếp tiếp theo giữa người dùng và

73
00:05:18,790 --> 00:05:23,658
máy chủ, có thể được thực hiện đơn giản bằng cách sử dụng mã thông báo này.

74
00:05:23,658 --> 00:05:29,240
JSON Web Token mà chúng ta sẽ nói về, là một

75
00:05:29,240 --> 00:05:35,465
chương trình xác thực dựa trên Token như vậy, và có máy chủ khi nó tạo ra mã thông báo này, nó sẽ tạo ra một mã thông báo đã ký.

76
00:05:35,465 --> 00:05:40,315
Sử dụng một bí mật trên trang web máy chủ mà chỉ có máy chủ biết.

77
00:05:40,315 --> 00:05:43,965
Do đó, ngay cả khi một bên thứ ba ở giữa và

78
00:05:43,965 --> 00:05:49,185
cố gắng thao tác mã thông báo, ngay cả khi nó chụp mã thông báo và

79
00:05:49,185 --> 00:05:53,045
cố gắng thao tác mã thông báo, mã thông báo sẽ trở nên không hợp lệ.

80
00:05:53,045 --> 00:05:57,201
Và như vậy, cách bảo vệ người dùng đó là

81
00:05:57,201 --> 00:06:02,250
dễ dàng khả thi, tất cả các yêu cầu tiếp theo

82
00:06:02,250 --> 00:06:07,430
từ phía khách hàng nên mang theo mã thông báo trong yêu cầu

83
00:06:07,430 --> 00:06:11,870
, hoặc, như tôi đã nói, trong tiêu đề hoặc trong nội dung của thông điệp yêu cầu.

84
00:06:11,870 --> 00:06:16,120
Vì vậy, khi máy chủ nhận được mã thông báo này, máy chủ sẽ xác minh mã thông báo,

85
00:06:16,120 --> 00:06:20,810
để đảm bảo rằng đây là mã thông báo hợp lệ, và sau đó nếu nó là mã thông báo hợp lệ,

86
00:06:20,810 --> 00:06:25,430
máy chủ sau đó sẽ đáp ứng yêu cầu đến.

87
00:06:25,430 --> 00:06:31,210
Như tôi đã đề cập, JSON Web Tokens là một chương trình xác thực dựa trên Token.

88
00:06:31,210 --> 00:06:35,838
JSON Web Token, là một cách rất đơn giản để mã hóa

89
00:06:35,838 --> 00:06:41,174
thông tin trong một mã thông báo sau đó chuyển nó đến trang web khách hàng.

90
00:06:41,174 --> 00:06:45,702
JSON Web Token chính nó dựa trên các tiêu chuẩn,

91
00:06:45,702 --> 00:06:49,670
điều này dựa trên IETF RFC 7519.

92
00:06:49,670 --> 00:06:53,499
IETF ở đây, là viết tắt của Internet Engineering Task Force.

93
00:06:53,499 --> 00:07:00,011
Tổ chức yêu cầu tất cả mọi thứ về cách thức hoạt động của internet,

94
00:07:00,011 --> 00:07:06,427
và đề cập đến các giao thức và các chính sách, liên quan đến internet.

95
00:07:06,427 --> 00:07:10,391
RFC, là viết tắt của tài liệu tiêu chuẩn,

96
00:07:10,391 --> 00:07:15,270
theo thuật ngữ IETF, RFC là viết tắt của Request for Comments.

97
00:07:15,270 --> 00:07:18,650
Và mỗi tài liệu tiêu chuẩn như vậy mang một số.

98
00:07:18,650 --> 00:07:23,560
7519 trong trường hợp này đề cập đến tài liệu, tài liệu

99
00:07:23,560 --> 00:07:27,250
tiêu chuẩn liên quan đến JSON Web Token.

100
00:07:27,250 --> 00:07:31,420
JSON Web Token chính nó là một mã thông báo tự chứa, nó mang tất cả

101
00:07:31,420 --> 00:07:37,250
các thông tin bên trong chính nó, đó là cần thiết để xác định người dùng.

102
00:07:37,250 --> 00:07:43,080
Không chỉ vậy, một JSON Web Token có thể được chia sẻ giữa hai ứng dụng.

103
00:07:43,080 --> 00:07:46,930
Vì vậy, ví dụ, một ứng dụng khi nó authenticates và sau đó được giữ của

104
00:07:46,930 --> 00:07:51,760
một JSON Web Token, có thể vượt qua rằng JSON Web Token để và trong ứng dụng

105
00:07:51,760 --> 00:07:56,950
đó, rằng nó sẵn sàng cho phép để truy cập vào máy chủ thay mặt nó.

106
00:07:56,950 --> 00:08:00,200
Việc chia sẻ mã thông báo này được thực hiện một cách rất an toàn,

107
00:08:00,200 --> 00:08:03,460
vì vậy đừng lo lắng quá nhiều về bảo mật trong đó.

108
00:08:03,460 --> 00:08:04,990
Đây không phải là một cách an toàn,

109
00:08:04,990 --> 00:08:09,090
mà bằng cách chia sẻ mã thông báo giữa một ứng dụng khác.

110
00:08:09,090 --> 00:08:13,250
Do đó, ủy quyền được chuyển giao cho một ứng dụng thứ hai, và

111
00:08:13,250 --> 00:08:17,740
ứng dụng thứ hai có thể ủy quyền thay mặt cho ứng dụng đầu tiên,

112
00:08:17,740 --> 00:08:18,990
để giao tiếp với máy chủ.

113
00:08:20,200 --> 00:08:24,200
Điều này là khả thi với thẻ.

114
00:08:24,200 --> 00:08:28,710
Bây giờ tất nhiên, các kỹ sư trong bạn rõ ràng sẽ tự hỏi chính xác những gì là

115
00:08:28,710 --> 00:08:32,690
bên trong một JSON Web Token, và nó hữu ích như thế nào?

116
00:08:32,690 --> 00:08:39,120
Một JSON Web Token, như tôi đã nói, được mã hóa thành một chuỗi dài và

117
00:08:39,120 --> 00:08:43,530
chuỗi này chính nó có thể được hiểu là bao gồm ba phần.

118
00:08:43,530 --> 00:08:49,470
Chuỗi chính nó có thể, hoặc chuỗi mã hóa chính nó chứa ba

119
00:08:49,470 --> 00:08:52,896
phần, Header, Payload và Chữ ký. Điều

120
00:08:52,896 --> 00:08:59,070
đó mang đủ thông tin về cách mã thông báo này được mã hóa.

121
00:08:59,070 --> 00:09:03,780
Tiêu đề chính nó chứa các thuật toán cụ thể được sử dụng để

122
00:09:03,780 --> 00:09:08,460
mã hóa mã hóa JSON Web Token này, và loại mã thông báo chính nó.

123
00:09:08,460 --> 00:09:16,280
Các thuật toán trong trường hợp này, sẽ là HS256 mà là một lược đồ mã hóa 256 bit,

124
00:09:16,280 --> 00:09:21,140
được sử dụng để băm thông tin bên trong của mã thông báo.

125
00:09:21,140 --> 00:09:24,350
Và trong trường hợp này, điều này xảy ra là JSON Web Token, và do đó

126
00:09:24,350 --> 00:09:27,870
trường loại sẽ được đặt thành JWT.

127
00:09:27,870 --> 00:09:33,210
Và đó là thông tin được lưu trữ trong tiêu đề của JSON Web Token.

128
00:09:33,210 --> 00:09:38,800
Bản thân Payload, mang thông tin giúp bạn xác định người dùng.

129
00:09:38,800 --> 00:09:41,440
Trong bài tập mà chúng tôi sẽ làm,

130
00:09:41,440 --> 00:09:46,730
tải trọng giờ chỉ mang theo ID của người dùng bên trong tải trọng.

131
00:09:46,730 --> 00:09:48,720
Không có thông tin nào khác là cần thiết.

132
00:09:48,720 --> 00:09:51,690
ID này có thể được sử dụng ở phía máy chủ,

133
00:09:51,690 --> 00:09:58,350
để lập chỉ mục vào Mongo DB để lấy thông tin người dùng đầy đủ nếu cần.

134
00:09:58,350 --> 00:10:02,050
Vì vậy, bạn sẽ thấy rằng chúng tôi sẽ mã hóa ID và

135
00:10:02,050 --> 00:10:05,020
sau đó lưu trữ nó trong tải trọng của tin nhắn đó.

136
00:10:05,020 --> 00:10:09,470
Bạn có thể lưu trữ thông tin bổ sung trong tải trọng của thư nếu bạn yêu cầu.

137
00:10:09,470 --> 00:10:11,410
Nhưng càng có nhiều thông tin mà bạn lưu trữ ở đó,

138
00:10:11,410 --> 00:10:15,720
càng lớn JSON Web Token tương ứng sẽ đến với tôi.

139
00:10:15,720 --> 00:10:20,010
Vì vậy, cố gắng giới hạn số lượng thông tin mà bạn lưu trữ trong tải trọng

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

141
00:10:22,155 --> 00:10:27,545
Như chúng ta sẽ thấy trong bài tập, chúng tôi có một mô-đun nút cho

142
00:10:27,545 --> 00:10:30,875
phép chúng tôi mã hóa và tạo ra một mã hóa JSON Web Token,

143
00:10:30,875 --> 00:10:34,395
dựa trên thông tin mà chúng tôi muốn đưa vào tải trọng.

144
00:10:34,395 --> 00:10:38,735
Bây giờ, khi bạn tạo một JSON Web Token, bạn cũng cung cấp một chữ ký.

145
00:10:38,735 --> 00:10:44,929
Một khóa bí mật ở phía máy chủ được sử dụng để mã hóa mã hóa JSON Web Token này,

146
00:10:44,929 --> 00:10:51,044
và bí mật đó cũng được bao gồm trong phần chữ ký của JSON Web Token.

147
00:10:51,044 --> 00:10:55,232
Bản thân chữ ký được bao gồm theo cách mà có

148
00:10:55,232 --> 00:10:58,797
một điều cơ bản trước khi mã hóa tiêu đề và tải trọng,

149
00:10:58,797 --> 00:11:04,750
sau đó được mã hóa bằng cách sử dụng bí mật cụ thể được sử dụng bởi máy chủ.

150
00:11:04,750 --> 00:11:08,644
Và điều này được mã hóa trong, như tôi đã nói HMAC,

151
00:11:08,644 --> 00:11:14,144
mà chúng tôi đã đề cập đến trong một trong những bài học trước đó và

152
00:11:14,144 --> 00:11:20,922
sử dụng băm 256 bit, và đó là bao gồm trong chữ ký.

153
00:11:20,922 --> 00:11:25,118
Vì vậy, khi JSON Web Token này được nhận ở phía máy chủ, và

154
00:11:25,118 --> 00:11:30,094
khi máy chủ giải mã mã thông báo này, thì máy chủ có thể kiểm tra chéo để

155
00:11:30,094 --> 00:11:34,525
đảm bảo rằng JSON Web Token này đã không bị giả mạo bởi bất cứ ai,

156
00:11:34,525 --> 00:11:39,460
trong khi mã thông báo đang được thông qua giữa máy khách và trang web máy chủ.

157
00:11:39,460 --> 00:11:43,020
Vì vậy, nếu bạn biết bất cứ điều gì về bảo mật,

158
00:11:43,020 --> 00:11:47,670
và những kẻ xâm nhập, và vân vân, bạn hiểu tại sao điều quan trọng là mã hóa mã thông báo, và xác

159
00:11:47,670 --> 00:11:53,250
minh tính xác thực của mã thông báo trên trang web máy chủ.

160
00:11:53,250 --> 00:11:58,640
Như tôi đã đề cập, nếu bạn cần phải đối phó với JSON Web Token trong ứng dụng nút của bạn.

161
00:11:58,640 --> 00:12:02,810
Có một mô-đun nút cụ thể được gọi là jsonwebtoken Node Module.

162
00:12:02,810 --> 00:12:07,830
Mô-đun nút này thực hiện các tiêu chuẩn liên quan đến JSON Web Token, và

163
00:12:07,830 --> 00:12:10,640
nó có thể được đưa vào ứng dụng nút của bạn.

164
00:12:10,640 --> 00:12:15,190
Mô-đun này chính nó, cung cấp một phương pháp gọi là dấu hiệu cho phép bạn ký và

165
00:12:15,190 --> 00:12:18,910
phát hành mã thông báo cho khách hàng từ phía máy chủ.

166
00:12:18,910 --> 00:12:21,820
Nó cũng chứa một phương pháp xác minh.

167
00:12:21,820 --> 00:12:27,040
Có thể được sử dụng để xác minh tính xác thực hoặc

168
00:12:27,040 --> 00:12:33,380
để đảm bảo tính xác thực của mã thông báo JSON Web đến,

169
00:12:33,380 --> 00:12:38,620
vì vậy chúng tôi sẽ sử dụng mô-đun mã thông báo JSON Web, trong bài tập của chúng tôi.

170
00:12:38,620 --> 00:12:42,010
Cùng với mô-đun JSON Web Token,

171
00:12:42,010 --> 00:12:47,450
chúng tôi cũng sử dụng mô-đun Passport-JWT, mô-đun nút. Trong

172
00:12:47,450 --> 00:12:54,547
đó cung cấp các chiến lược dựa trên jwt cho mô-đun chứng thực hộ chiếu của chúng tôi.

173
00:12:54,547 --> 00:12:59,441
Vì vậy, điều này cung cấp một chiến lược hộ chiếu để xác thực bằng cách sử dụng JSON Web Token.

174
00:12:59,441 --> 00:13:06,153
Vì vậy, điều này cho phép bạn xác thực RESTful điểm cuối bằng cách sử dụng JWT như là phương pháp cho

175
00:13:06,153 --> 00:13:12,240
dong xác nhận, mà không yêu cầu máy chủ sử dụng phiên.

176
00:13:12,240 --> 00:13:17,300
Bây giờ, mô-đun hộ chiếu JWT,

177
00:13:17,300 --> 00:13:21,710
hỗ trợ một phương pháp thậm chí trích xuất mã thông báo JWT từ

178
00:13:21,710 --> 00:13:26,970
thông báo yêu cầu đến, và sau đó thậm chí xác minh mã thông báo thay mặt bạn.

179
00:13:26,970 --> 00:13:31,470
Thực tập sinh mô-đun Passport-JWT, sử dụng mô-đun JSON Web Token để

180
00:13:31,470 --> 00:13:34,550
thực hiện việc xác minh JSON Web Token đó.

181
00:13:34,550 --> 00:13:40,300
Bản thân mã thông báo có thể được thực hiện trong tiêu đề của yêu cầu đến,

182
00:13:40,300 --> 00:13:44,350
trong tiêu đề, ngay cả trong tiêu đề xác thực của yêu cầu đến,

183
00:13:44,350 --> 00:13:46,940
đó là những gì chúng tôi sẽ làm trong bài tập.

184
00:13:46,940 --> 00:13:51,420
Mã thông báo cũng có thể được thực hiện trong phần thân của yêu cầu đến, trong trường hợp đó,

185
00:13:51,420 --> 00:13:54,610
chúng ta phải trích xuất mã thông báo từ phần thân của yêu cầu đến và

186
00:13:54,610 --> 00:13:56,352
sau đó sử dụng nó.

187
00:13:56,352 --> 00:14:01,170
Các mô-đun Passport-JWT, cũng hỗ trợ điều đó nếu bạn chọn để

188
00:14:01,170 --> 00:14:06,580
sử dụng như là cách để chuyển token trở lại từ khách hàng đến trang web máy chủ.

189
00:14:06,580 --> 00:14:11,600
Các JSON Web Token, cũng có thể được bao gồm trong các tham số truy vấn URL nếu bạn nên

190
00:14:11,600 --> 00:14:16,440
chọn để, và có thể được trích xuất từ đó b Passport-JWT và

191
00:14:16,440 --> 00:14:18,370
được sử dụng để xác thực.

192
00:14:18,370 --> 00:14:22,783
Bây giờ, với sự hiểu biết nhanh chóng về JSON Web Token và

193
00:14:22,783 --> 00:14:27,915
cách chúng hữu ích, chúng tôi sẽ chuyển sang bài tập nơi chúng tôi sẽ sử dụng mô-đun

194
00:14:27,915 --> 00:14:33,230
Passport-JWT, cùng với mô-đun JSON Web Token,

195
00:14:33,230 --> 00:14:38,211
và cấu hình máy chủ Express Rest API của chúng tôi để sử dụng JSON Web Token.

196
00:14:38,211 --> 00:14:41,589
[ NHẠC]