Tôi đã đọc về xác thực và trở nên khó hiểu về phân loại.

Hãy bắt đầu từ xác thực dựa trên Cookie, Nếu tôi hiểu đúng, điểm quan trọng là tất cả dữ liệu, cần thiết cho xác thực người dùng, được lưu trữ trong cookie. Và đây là sự nhầm lẫn đầu tiên của tôi: trong cookie chúng tôi có thể lưu trữ

• id phiên và vì vậy nó trở thành một xác thực dựa trên phiên?
• khiếu nại, và do đó, nó có nên được gọi là xác thực dựa trên Yêu cầu không?
• Tôi đã thấy rằng một số người thậm chí lưu trữ mã thông báo JWT trong cookie, nhưng điều này có vẻ như là một triển khai tùy chỉnh của luồng xác thực riêng ...

Bây giờ hãy chuyển sang xác thực dựa trên yêu cầu. Yếu tố chính là khiếu nại và tập hợp các yêu cầu có thể sử dụng làm container

• cookie (như đã thảo luận ở trên)
• mã thông báo (JWT làm ví dụ).

Từ phía bên kia, khi chúng ta đang nói về mã thông báo, nó có thể chứa bất kỳ loại thông tin nào ... Ví dụ về Id phiên ...

Vì vậy, những gì tôi đã bỏ lỡ? Tại sao mọi người không định nghĩa một cái gì đó như Cookie-Session-basedhoặc Token-Claims-basedxác thực khi nói về các loại xác thực?

Tôi đồng ý rằng việc đặt tên của các khái niệm khác nhau là khó hiểu. Khi nói về xác thực trong ngữ cảnh web, có một số khía cạnh cần xem xét.

Khách hàng gửi thông tin gì khi xác thực?

• Một phiên id . Điều này có nghĩa là máy chủ có bộ lưu trữ phiên chứa các phiên hoạt động. Các phiên có trạng thái ở phía máy chủ.
• Một bộ các yêu cầu . Khiếu nại có chứa thông tin về những hoạt động khách hàng có thể thực hiện. Máy chủ không theo dõi từng khách hàng được xác thực, nhưng tin tưởng vào các khiếu nại. Khiếu nại thường không trạng thái ở phía máy chủ.

Làm thế nào để khách hàng gửi thông tin xác thực?

• Bánh quy . Trình duyệt gửi cookie tự động với mỗi yêu cầu, sau khi cookie đã được đặt. Cookies dễ bị tấn công XSRF.
• Các tiêu đề khác . Thông thường, tiêu đề ủy quyền được sử dụng cho việc này. Các tiêu đề này không được trình duyệt tự động gửi mà phải được thiết lập bởi máy khách. Điều này dễ bị tổn thương với XSS.
• Yêu cầu Url . Thông tin xác thực được bao gồm trong URL. Điều này không được sử dụng phổ biến.

Định dạng của thông tin xác thực là gì?

• Văn bản đơn giản, không dấu . Điều này có thể được sử dụng cho id phiên. Một id phiên thường không thể đoán được bởi máy khách, vì vậy máy chủ có thể tin tưởng rằng máy khách đã không giả mạo nó.
• Mã thông báo web Json . JWT được ký bằng mật mã và chứa thông tin hết hạn. Máy khách thường có thể giải mã mã thông báo, nhưng không thể thay đổi nó mà không cần máy chủ nhận thấy.
• Bất kỳ định dạng đã ký nào khác . Tương tự như JWT. Điều quan trọng là chữ ký điện tử, ngăn khách hàng thay đổi dữ liệu.

Phần thưởng: Làm thế nào để khách hàng lưu trữ thông tin tại địa phương

• Bánh quy . Tất nhiên đây là trường hợp khi sử dụng cookie để truyền thông tin. Nhưng Cookies cũng có thể được sử dụng như một cơ chế lưu trữ phía máy khách. Điều này đòi hỏi cookie phải có thể đọc được từ các tập lệnh để có ích. Ví dụ: khách hàng có thể đọc cookie bằng JavaScript và gửi thông tin với Tiêu đề ủy quyền.
• Lưu trữ cục bộ . Đây thường là phương pháp khả thi duy nhất, nếu cookie không có sẵn. Yêu cầu quản lý với JavaScript.

Mọi người có ý nghĩa gì khi họ nói ...

• "Xác thực dựa trên cookie" . Tôi thấy rằng điều này thường có nghĩa là "Id phiên, gửi bằng cookie, có thể dưới dạng văn bản thuần túy."
• "Xác thực dựa trên mã thông báo" . Thông thường, điều này có nghĩa là "Khiếu nại, gửi bằng tiêu đề xác thực, được mã hóa dưới dạng Mã thông báo Web Json."
• "Xác thực dựa trên yêu cầu" . Có thể là bất cứ điều gì ngoại trừ một id phiên.

Chỉ cần đặt,

1. Xác thực dựa trên cookie

   • Web-client (ví dụ: trình duyệt web) lưu trữ cookie được gửi bởi máy chủ web sau khi xác thực thành công.
   • Cookie chứa thông tin về người dùng, ứng dụng khách, dấu thời gian authN và dữ liệu hữu ích khác với id duy nhất để xác định cookie.
   • Thông thường, cookie được mã hóa bởi máy chủ web với bộ thuộc tính miền (ví dụ: google.com :) và gửi nó đến máy khách web.
   • Bất cứ khi nào máy khách web muốn truy cập tài nguyên miền (ví dụ mail.google.com:), nó sẽ gửi tất cả cookie dựa trên tên miền của nó (ví dụ google.com:) đến máy chủ web, xác nhận / xác minh và cấp / từ chối truy cập dựa trên trạng thái và dấu thời gian của bánh quy.

2. Xác thực dựa trên phiên

   • Cùng với cookie máy khách web, nếu máy chủ web lưu trữ dữ liệu authN của người dùng trong back-end của họ, thì nó sẽ được gọi là xác thực dựa trên phiên.
   • Điều này rất hữu ích trong trường hợp có bất kỳ vi phạm nào mà máy khách web có được quyền truy cập vào hệ thống mà nó không được truy cập, sau đó từ back-end, phiên của khách hàng web có thể bị thu hồi bởi quản trị viên.

3. Xác thực dựa trên mã thông báo

   • Nói chung, điều này được sử dụng trong các tình huống không phải máy khách, trong đó không có cách nào để lưu trữ cookie ở phía máy khách.
   • Do đó, máy chủ web sẽ gửi mã thông báo đã ký (chứa thông tin về người dùng, máy khách, dấu thời gian authN và dữ liệu hữu ích khác với id duy nhất) cho khách hàng sau khi xác thực thành công.
   • Bất cứ khi nào, khách hàng muốn truy cập tài nguyên, nó cần gửi mã thông báo này và máy chủ web xác thực / xác minh mã thông báo trước khi cho phép truy cập tài nguyên.

4. Xác thực dựa trên yêu cầu

   • Điều này giống như xác thực dựa trên mã thông báo, chỉ có điều nó thêm một số dữ liệu vào mã thông báo về máy khách và / hoặc người dùng được liên kết với máy khách.
   • Những dữ liệu này liên quan đến ủy quyền, trong đó nói về những gì khách hàng sẽ làm trong tài nguyên (ví dụ: mail.read, mail.delete, calendar.read).