[MUSIC]
Trong các bài học trước đây,
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.
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 để
thực hiện xác thực, và thậm chí cookie đã ký
, và sau đó, chúng tôi xem xét xác thực dựa trên phiên.
Nơi máy chủ đang theo dõi thông tin về mỗi khách hàng, và
sau đó cookie sẽ được sử dụng như một cách để lập chỉ mục vào
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.
Bây giờ, cookie và phiên dựa trên xác thực không có khả năng mở rộng,
bởi vì có máy chủ cần theo dõi tất cả những người dùng khác nhau.
Mặc dù, điều này được thực hiện bên ngoài giao thức HTTP, nhưng
vẫn là thực tế là bạn cần theo dõi
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.
Vì vậy, đây là nơi xác thực dựa trên Token đã
được chứng minh là rất hữu ích.
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à
bài tập sau.
Một lần nữa, nhanh chóng xem xét cookie và xác thực dựa trên phiên.
Với việc xác thực dựa
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
trong mỗi thông báo yêu cầu gửi đi, theo đó, máy chủ được nhắc nhở về
khách hàng cụ thể đó, bằng cách trích xuất thông tin từ cookie.
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,
và sau đó khi máy chủ nhận được yêu cầu đến từ cookie,
nó chiết xuất ID phiên và sử dụng đó như là một chỉ mục vào
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ể.
Bây giờ, cách tiếp cận này như tôi đã nói,
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
theo dõi tất cả hàng ngàn phiên ở phía máy chủ.
Mặc dù nó được thực hiện độc lập với HTTP trong một cửa hàng,
hoặc là một tập tin lưu trữ hoặc một cơ sở dữ liệu.
Tuy nhiên,
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.
Vì vậy, một lần nữa, để nhắc nhở bạn một lần nữa,
tại sao chúng ta lại nói về chứng thực dựa trên token?
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
ứng dụng web và có thể dễ dàng chăm sóc xác thực người dùng.
Nhưng sau đó, xác thực dựa trên phiên, trong khi đó là nguyên tắc của các
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.
Vấn đề thứ hai là, các ứng dụng di động không
xử lý xác thực dựa trên phiên rất tốt.
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.
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
cả một ứng dụng web, cũng như một ứng dụng di động.
Sau đó, xác thực dựa trên phiên sẽ không được rất hữu ích, và
đâ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.
Trong một xác thực dựa trên
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
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 đó.
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.
Hơn nữa, xác thực dựa trên token cũng giúp chúng tôi
giải quyết những vấn đề được gọi là CORS hoặc CSRF.
Các vấn đề chia sẻ tài nguyên chéo nguồn gốc và như vậy
, tôi sẽ nói ngắn gọn về chi phí trong mô-đun tiếp theo.
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ố
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.
Không chỉ vậy, xác thực dựa trên Token là rất dễ dàng hơn cho
một ứng dụng để chia sẻ xác thực của nó với một ứng dụng khác.
Tất nhiên, điều này được thực hiện một cách an toàn.
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.
Xác thực dựa trên Token hoạt động như thế nào?
Trong xác thực dựa trên Token,
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ủ.
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 đó.
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.
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
công nghệ như, oauth hoặc oauth 2.0 hoặc mở ID.
Chúng ta sẽ nói ngắn gọn về oauth và oauth 2.0 trong mô-đun tiếp theo.
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
đượ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.
Và tất cả các giao tiếp tiếp tiếp theo giữa người dùng và
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.
JSON Web Token mà chúng ta sẽ nói về, là một
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ý.
Sử dụng một bí mật trên trang web máy chủ mà chỉ có máy chủ biết.
Do đó, ngay cả khi một bên thứ ba ở giữa và
cố gắng thao tác mã thông báo, ngay cả khi nó chụp mã thông báo và
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ệ.
Và như vậy, cách bảo vệ người dùng đó là
dễ dàng khả thi, tất cả các yêu cầu tiếp theo
từ phía khách hàng nên mang theo mã thông báo trong yêu cầu
, 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.
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,
để đả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ệ,
máy chủ sau đó sẽ đáp ứng yêu cầu đến.
Như tôi đã đề cập, JSON Web Tokens là một chương trình xác thực dựa trên Token.
JSON Web Token, là một cách rất đơn giản để mã hóa
thông tin trong một mã thông báo sau đó chuyển nó đến trang web khách hàng.
JSON Web Token chính nó dựa trên các tiêu chuẩn,
điều này dựa trên IETF RFC 7519.
IETF ở đây, là viết tắt của Internet Engineering Task Force.
Tổ chức yêu cầu tất cả mọi thứ về cách thức hoạt động của internet,
và đề cập đến các giao thức và các chính sách, liên quan đến internet.
RFC, là viết tắt của tài liệu tiêu chuẩn,
theo thuật ngữ IETF, RFC là viết tắt của Request for Comments.
Và mỗi tài liệu tiêu chuẩn như vậy mang một số.
7519 trong trường hợp này đề cập đến tài liệu, tài liệu
tiêu chuẩn liên quan đến JSON Web Token.
JSON Web Token chính nó là một mã thông báo tự chứa, nó mang tất cả
các thông tin bên trong chính nó, đó là cần thiết để xác định người dùng.
Không chỉ vậy, một JSON Web Token có thể được chia sẻ giữa hai ứng dụng.
Vì vậy, ví dụ, một ứng dụng khi nó authenticates và sau đó được giữ của
một JSON Web Token, có thể vượt qua rằng JSON Web Token để và trong ứng dụng
đó, rằng nó sẵn sàng cho phép để truy cập vào máy chủ thay mặt nó.
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,
vì vậy đừng lo lắng quá nhiều về bảo mật trong đó.
Đây không phải là một cách an toàn,
mà bằng cách chia sẻ mã thông báo giữa một ứng dụng khác.
Do đó, ủy quyền được chuyển giao cho một ứng dụng thứ hai, và
ứng dụng thứ hai có thể ủy quyền thay mặt cho ứng dụng đầu tiên,
để giao tiếp với máy chủ.
Điều này là khả thi với thẻ.
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à
bên trong một JSON Web Token, và nó hữu ích như thế nào?
Một JSON Web Token, như tôi đã nói, được mã hóa thành một chuỗi dài và
chuỗi này chính nó có thể được hiểu là bao gồm ba phần.
Chuỗi chính nó có thể, hoặc chuỗi mã hóa chính nó chứa ba
phần, Header, Payload và Chữ ký. Điều
đó mang đủ thông tin về cách mã thông báo này được mã hóa.
Tiêu đề chính nó chứa các thuật toán cụ thể được sử dụng để
mã hóa mã hóa JSON Web Token này, và loại mã thông báo chính nó.
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,
được sử dụng để băm thông tin bên trong của mã thông báo.
Và trong trường hợp này, điều này xảy ra là JSON Web Token, và do đó
trường loại sẽ được đặt thành JWT.
Và đó là thông tin được lưu trữ trong tiêu đề của JSON Web Token.
Bản thân Payload, mang thông tin giúp bạn xác định người dùng.
Trong bài tập mà chúng tôi sẽ làm,
tải trọng giờ chỉ mang theo ID của người dùng bên trong tải trọng.
Không có thông tin nào khác là cần thiết.
ID này có thể được sử dụng ở phía máy chủ,
để lập chỉ mục vào Mongo DB để lấy thông tin người dùng đầy đủ nếu cần.
Vì vậy, bạn sẽ thấy rằng chúng tôi sẽ mã hóa ID và
sau đó lưu trữ nó trong tải trọng của tin nhắn đó.
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.
Nhưng càng có nhiều thông tin mà bạn lưu trữ ở đó,
càng lớn JSON Web Token tương ứng sẽ đến với tôi.
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
của JSON Web Token.
Như chúng ta sẽ thấy trong bài tập, chúng tôi có một mô-đun nút cho
phép chúng tôi mã hóa và tạo ra một mã hóa JSON Web Token,
dựa trên thông tin mà chúng tôi muốn đưa vào tải trọng.
Bây giờ, khi bạn tạo một JSON Web Token, bạn cũng cung cấp một chữ ký.
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,
và bí mật đó cũng được bao gồm trong phần chữ ký của JSON Web Token.
Bản thân chữ ký được bao gồm theo cách mà có
một điều cơ bản trước khi mã hóa tiêu đề và tải trọng,
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ủ.
Và điều này được mã hóa trong, như tôi đã nói HMAC,
mà chúng tôi đã đề cập đến trong một trong những bài học trước đó và
sử dụng băm 256 bit, và đó là bao gồm trong chữ ký.
Vì vậy, khi JSON Web Token này được nhận ở phía máy chủ, và
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 để
đảm bảo rằng JSON Web Token này đã không bị giả mạo bởi bất cứ ai,
trong khi mã thông báo đang được thông qua giữa máy khách và trang web máy chủ.
Vì vậy, nếu bạn biết bất cứ điều gì về bảo mật,
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
minh tính xác thực của mã thông báo trên trang web máy chủ.
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.
Có một mô-đun nút cụ thể được gọi là jsonwebtoken Node Module.
Mô-đun nút này thực hiện các tiêu chuẩn liên quan đến JSON Web Token, và
nó có thể được đưa vào ứng dụng nút của bạn.
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à
phát hành mã thông báo cho khách hàng từ phía máy chủ.
Nó cũng chứa một phương pháp xác minh.
Có thể được sử dụng để xác minh tính xác thực hoặc
để đảm bảo tính xác thực của mã thông báo JSON Web đến,
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.
Cùng với mô-đun JSON Web Token,
chúng tôi cũng sử dụng mô-đun Passport-JWT, mô-đun nút. Trong
đó 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.
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.
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
dong xác nhận, mà không yêu cầu máy chủ sử dụng phiên.
Bây giờ, mô-đun hộ chiếu JWT,
hỗ trợ một phương pháp thậm chí trích xuất mã thông báo JWT từ
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.
Thực tập sinh mô-đun Passport-JWT, sử dụng mô-đun JSON Web Token để
thực hiện việc xác minh JSON Web Token đó.
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,
trong tiêu đề, ngay cả trong tiêu đề xác thực của yêu cầu đến,
đó là những gì chúng tôi sẽ làm trong bài tập.
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 đó,
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à
sau đó sử dụng nó.
Các mô-đun Passport-JWT, cũng hỗ trợ điều đó nếu bạn chọn để
sử dụng như là cách để chuyển token trở lại từ khách hàng đến trang web máy chủ.
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
chọn để, và có thể được trích xuất từ đó b Passport-JWT và
được sử dụng để xác thực.
Bây giờ, với sự hiểu biết nhanh chóng về JSON Web Token và
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
Passport-JWT, cùng với mô-đun JSON Web Token,
và cấu hình máy chủ Express Rest API của chúng tôi để sử dụng JSON Web Token.
[ NHẠC]