Tôi đã đọc một số bài đăng về "JWT vs Cookie" nhưng chúng chỉ khiến tôi thêm bối rối ...

1. Tôi muốn làm rõ , khi mọi người nói về "xác thực dựa trên mã thông báo và cookie", cookie ở đây chỉ đơn thuần là cookie phiên ? Tôi hiểu rằng cookie giống như một phương tiện , nó có thể được sử dụng để triển khai xác thực dựa trên mã thông báo (lưu trữ thứ có thể xác định người dùng đã đăng nhập ở phía máy khách ) hoặc xác thực dựa trên phiên (lưu trữ một hằng số ở phía máy khách khớp với thông tin phiên ở phía máy chủ )

2. Tại sao chúng ta cần mã thông báo web JSON ? Tôi đang sử dụng cookie tiêu chuẩn để triển khai xác thực dựa trên mã thông báo ( không sử dụng id phiên, không sử dụng bộ nhớ máy chủ hoặc lưu trữ tệp ): Set-Cookie: user=innocent; preferred-color=azurevà sự khác biệt duy nhất mà tôi quan sát được là JWT chứa cả tải trọng và chữ ký ... trong khi bạn có thể chọn giữa cookie đã ký hoặc văn bản rõ ràng cho tiêu đề http. Theo ý kiến ​​của tôi, cookie đã ký ( cookie:'time=s%3A1464743488946.WvSJxbCspOG3aiGi4zCMMR9yBdvS%2B6Ob2f3OG6%2FYCJM') hiệu quả hơn về không gian, hạn chế duy nhất là máy khách không thể đọc mã thông báo, chỉ máy chủ mới có thể ... nhưng tôi nghĩ nó ổn vì giống như xác nhận quyền sở hữu trong JWT là tùy chọn, nó không cần thiết cho mã thông báo có ý nghĩa

Sự khác biệt lớn nhất giữa mã thông báo không mang và cookie là trình duyệt sẽ tự động gửi cookie , trong đó mã thông báo không có ghi cần phải được thêm một cách rõ ràng vào yêu cầu HTTP.

Tính năng này làm cho cookie trở thành một cách tốt để bảo mật các trang web, nơi người dùng đăng nhập và điều hướng giữa các trang bằng liên kết.

Việc trình duyệt tự động gửi cookie cũng có một nhược điểm lớn, đó là các cuộc tấn công CSRF . Trong một cuộc tấn công CSRF, một trang web độc hại lợi dụng thực tế là trình duyệt của bạn sẽ tự động đính kèm cookie xác thực cho các yêu cầu đến miền đó và đánh lừa trình duyệt của bạn thực hiện một yêu cầu.

Giả sử trang web tại https://www.example.com cho phép người dùng đã xác thực thay đổi mật khẩu của họ bằng cách- POSTchuyển mật khẩu mới thành https://www.example.com/changepassword mà không yêu cầu đăng tên người dùng hoặc mật khẩu cũ.

Nếu bạn vẫn đăng nhập vào trang web đó khi bạn truy cập một trang web độc hại tải một trang trong trình duyệt của bạn kích hoạt ĐĂNG đến địa chỉ đó, trình duyệt của bạn sẽ đính kèm trung thực các cookie xác thực, cho phép kẻ tấn công thay đổi mật khẩu của bạn.

Cookie cũng có thể được sử dụng để bảo vệ các dịch vụ web, nhưng ngày nay các mã thông báo mang tên được sử dụng thường xuyên nhất. Nếu bạn sử dụng cookie để bảo vệ dịch vụ web của mình, dịch vụ đó cần phải tồn tại trên miền mà cookie xác thực được đặt, vì chính sách nguồn gốc sẽ không gửi cookie đến miền khác.

Ngoài ra, cookie khiến các ứng dụng không dựa trên trình duyệt (như ứng dụng dành cho thiết bị di động đến máy tính bảng) khó sử dụng API của bạn hơn.

Tổng quat

Những gì bạn đang yêu cầu là sự khác biệt giữa cookie và mã thông báo mang để gửi Mã thông báo web JSON (JWT) từ máy khách đến máy chủ.

Cả cookie và mã thông báo mang đều gửi dữ liệu.

Một điểm khác biệt là cookie dành cho việc gửi và lưu trữ dữ liệu tùy ý, trong khi mã thông báo không mang tên cụ thể để gửi dữ liệu ủy quyền.

Dữ liệu đó thường được mã hóa dưới dạng JWT.

Bánh quy

Cookie là một cặp tên-giá trị, được lưu trữ trong trình duyệt web và có ngày hết hạn và miền được liên kết.

Chúng tôi lưu trữ cookie trong trình duyệt web bằng JavaScript hoặc bằng tiêu đề Phản hồi HTTP.

document.cookie = 'my_cookie_name=my_cookie_value'   // JavaScript
Set-Cookie: my_cookie_name=my_cookie_value           // HTTP Response Header

Trình duyệt web tự động gửi cookie với mọi yêu cầu đến miền của cookie.

GET http://www.bigfont.ca
Cookie: my_cookie_name=my_cookie_value               // HTTP Request Header

Bearer Token

Mã thông báo mang là một giá trị đi vào Authorizationtiêu đề của bất kỳ Yêu cầu HTTP nào. Nó không được lưu trữ tự động ở bất kỳ đâu, nó không có ngày hết hạn và không có miền liên kết. Nó chỉ là một giá trị. Chúng tôi lưu trữ thủ công giá trị đó trong khách hàng của mình và thêm giá trị đó vào tiêu đề Ủy quyền HTTP theo cách thủ công.

GET http://www.bigfont.ca
Authorization: Bearer my_bearer_token_value          // HTTP Request Header

JWT và xác thực dựa trên mã thông báo

Khi chúng tôi thực hiện xác thực dựa trên mã thông báo, chẳng hạn như OpenID, OAuth hoặc OpenID Connect, chúng tôi nhận được access_token (và đôi khi là id_token) từ một cơ quan đáng tin cậy. Thông thường, chúng tôi muốn lưu trữ nó và gửi nó cùng với Yêu cầu HTTP cho các tài nguyên được bảo vệ. làm sao chúng ta làm việc đó bây giờ?

Tùy chọn 1 là lưu trữ (các) mã thông báo trong cookie. Điều này xử lý bộ nhớ và cũng tự động gửi (các) mã thông báo đến máy chủ trong Cookietiêu đề của mỗi yêu cầu. Sau đó, máy chủ phân tích cú pháp cookie, kiểm tra (các) mã thông báo và phản hồi tương ứng.

Một tùy chọn khác là lưu trữ mã thông báo trong bộ nhớ cục bộ / phiên, sau đó đặt thủ công Authorizationtiêu đề của mỗi yêu cầu. Trong trường hợp này, máy chủ đọc tiêu đề và tiến hành giống như với cookie.

Bạn nên đọc các RFC được liên kết để tìm hiểu thêm.

Ngoài những gì MvdD đã nói về việc cookie được gửi tự động:

1. Cookie có thể là một phương tiện, nhưng chức năng quan trọng nhất của nó là cách nó tương tác với trình duyệt. Cookie được thiết lập bởi máy chủ và gửi yêu cầu theo những cách rất cụ thể. Mặt khác, JWT chỉ là một phương tiện độc quyền, nó là sự khẳng định một số dữ kiện trong một cấu trúc cụ thể. Nếu bạn muốn như vậy, bạn có thể đặt JWT làm cookie xác thực của mình. Khi bạn đọc các bài viết so sánh chúng, họ thường nói về việc sử dụng JWT được gửi dưới dạng mã thông báo mang theo mã giao diện người dùng so với cookie xác thực tương ứng với một số phiên được lưu trong bộ nhớ cache hoặc dữ liệu người dùng ở mặt sau.
2. JWT cung cấp nhiều tính năng và đưa chúng vào một tiêu chuẩn để chúng có thể được sử dụng giữa các bên. JWT có thể hoạt động như một xác nhận có chữ ký của một số sự kiện ở nhiều nơi khác nhau. Một cookie, bất kể bạn đưa vào dữ liệu nào hoặc bạn ký tên vào nó, chỉ thực sự có ý nghĩa khi sử dụng giữa một trình duyệt và một back end cụ thể. JWT có thể được sử dụng từ trình duyệt đến back end, giữa các back end do các bên khác nhau kiểm soát (OpenId Connect là một ví dụ) hoặc trong các dịch vụ back end của một bên. Về ví dụ cụ thể của bạn về cookie đã ký của bạn, bạn có thể đạt được các chức năng tương tự ("không sử dụng id phiên, không sử dụng bộ nhớ máy chủ hoặc lưu trữ tệp") như JWT trong trường hợp sử dụng đó, nhưng bạn mất thư viện và đánh giá ngang hàng tiêu chuẩn, ngoài các vấn đề CSRF được đề cập trong câu trả lời khác.

Tóm lại: các bài đăng bạn đang đọc có thể đang so sánh JWT như một mã thông báo mang đến cookie xác thực cho mục đích xác thực trình duyệt với máy chủ. Nhưng JWT có thể làm được nhiều hơn thế, nó mang đến sự chuẩn hóa và các tính năng để sử dụng bên ngoài trường hợp sử dụng mà bạn có thể đang nghĩ đến.

Mặc dù cookie có thể làm tăng nguy cơ bị tấn công CSRF do chúng được gửi tự động cùng với các yêu cầu, chúng có thể giảm nguy cơ bị tấn công XSS khi HttpOnlycờ được đặt, vì bất kỳ tập lệnh nào được đưa vào trang sẽ không thể đọc được bánh quy.

CSRF: người dùng nhấp vào liên kết (hoặc xem hình ảnh) trên trang của kẻ tấn công, điều này khiến trình duyệt gửi yêu cầu đến trang của nạn nhân. Nếu nạn nhân sử dụng cookie, trình duyệt sẽ tự động đưa cookie vào yêu cầu và nếu yêu cầu GET có thể gây ra bất kỳ hành động không chỉ đọc nào, trang web của nạn nhân rất dễ bị tấn công.

XSS: kẻ tấn công nhúng một tập lệnh vào trang nạn nhân (trang nạn nhân chỉ dễ bị tấn công nếu đầu vào không được khử trùng đúng cách) và tập lệnh của kẻ tấn công có thể thực hiện bất kỳ điều gì mà javascript được phép làm trên trang. Nếu bạn lưu trữ mã thông báo JWT trong bộ nhớ cục bộ, tập lệnh của kẻ tấn công có thể đọc các mã thông báo đó và cũng gửi các mã thông báo đó đến máy chủ mà chúng kiểm soát. Nếu bạn sử dụng cookie với HttpOnlycờ, tập lệnh của kẻ tấn công sẽ không thể đọc cookie của bạn từ đầu. Điều đó nói rằng, tập lệnh mà họ đã chèn thành công sẽ vẫn có thể làm bất cứ điều gì mà javascript có thể làm, vì vậy bạn vẫn có IMO (tức là, trong khi họ có thể không đọc được cookie để gửi nó đến máy chủ của họ để sử dụng sau này , họ có thể gửi yêu cầu đến trang vicitim bằng XHR, trang này sẽ bao gồm cookie).

Tham khảo - Cần có Mã thông báo Web JSON

Bánh quy

Trong trường hợp có cookie, khi người dùng đã được xác thực thì Máy chủ Gmail sẽ tạo một Id phiên duy nhất. Tương ứng với id phiên này, nó sẽ lưu trong bộ nhớ tất cả thông tin người dùng mà máy chủ Gmail cần để nhận dạng người dùng và cho phép nó thực hiện các hoạt động.
Ngoài ra, đối với tất cả các yêu cầu và phản hồi tiếp theo, id phiên này cũng sẽ được chuyển. Vì vậy, bây giờ khi máy chủ nhận được yêu cầu, nó sẽ kiểm tra id phiên. Sử dụng id phiên này sẽ kiểm tra xem có bất kỳ thông tin tương ứng nào không. Sau đó, nó sẽ cho phép người dùng truy cập tài nguyên và trả lại phản hồi cùng với id phiên.

Hạn chế của Cookie

• Cookie / id phiên không được tự chứa. Nó là một mã thông báo tham chiếu. Trong mỗi lần xác thực, máy chủ Gmail cần tìm nạp thông tin tương ứng với nó.
• Không phù hợp với kiến ​​trúc microservices liên quan đến nhiều API và máy chủ

JWT

• JWT là độc lập. Nó là một mã thông báo giá trị. Vì vậy, trong mỗi lần xác thực, máy chủ Gmail không cần lấy thông tin tương ứng với nó.
• Nó được ký kỹ thuật số nên nếu có ai sửa đổi nó, máy chủ sẽ biết về nó
• Nó phù hợp nhất cho Kiến trúc Microservices
• Nó có những lợi thế khác như chỉ định thời gian hết hạn.