Xác thực qua mã thông báo

Tôi còn khá mới đối với jwt.io và xác thực và tôi đang sử dụng JWT.io theo cách sau.

Phía máy chủ

Khi người dùng đăng nhập, tôi tạo mã thông báo useridđược nhúng bên trong và chuyển lại cho người dùng trong nội dung thư

Trình duyệt phía máy khách / JS Tôi đang lưu trữ mã thông báo trong localStorage và cho mỗi yêu cầu tiếp theo, tôi sẽ chuyển mã thông báo trong các tiêu đề.

Authorization: Basic someEncryptedValue

Tôi cũng đã sử dụng

X-Auth-Token: someEncryptedValue

Tôi có thể sử dụng cái này trong một cái bánh quy không?

Sau đó, về phía máy chủ, tôi đang xác minh mã thông báo chống lại bí mật, kiểm tra hết hạn, lấy id ra khỏi mã thông báo và sau đó phục vụ yêu cầu.

Là tất cả mọi thứ chính xác trong quy trình làm việc này?

— người dùng2727195
nguồn

Bất kỳ lý do để không tuân theo một tiêu chuẩn như OAuth2? Btw: bạn không nên chuyển mã thông báo làm tiêu đề xác thực cơ bản, thay vào đó hãy sử dụng Ủy quyền: Người mang

— Arne Burmeister

vâng Bearer là một trong những quyền, OAuth2 là tôi giả sử là để người dùng xác thực thông qua bên thứ 3 như google, Facebook vv trong khi đây là cơ chế thẩm định của riêng tôi đối với người sử dụng mật khẩu, xin soi sáng cho tôi hơn nếu tôi sai

— user2727195

Auth bên thứ 3 chỉ là một tính năng của OAuth, hoạt động hoàn hảo với JWT và máy chủ xác thực riêng

— Arne Burmeister

ok, xin vui lòng khai sáng cho tôi với một số hướng dẫn dễ thực hiện

— user2727195

Không cần oAuth trừ khi bạn cần các ứng dụng chia sẻ thông tin giữa chúng. Đối với tính năng cơ bản như xác thực, Jwt là đủ.

— Laiv

Câu trả lời:

Quy trình làm việc của bạn là chính xác (giả sử bạn đang sử dụng HTTPS) và có, bạn chỉ có thể lưu trữ mã thông báo của mình trong Cookie thay vì chuyển nó trong tiêu đề ủy quyền.

Tôi không khuyên bạn nên sử dụng OAuth2. Việc thực hiện ngay cả luồng đơn giản nhất sẽ thêm một loạt phức tạp vào quy trình đăng nhập của bạn và có vẻ như tôi không cần nó vì các bộ phận "phía máy chủ" của bạn đều nằm trên cùng một miền.

Nếu là tôi, tôi sẽ sử dụng cookie. Bám sát các lược đồ được hiểu rõ sẽ ít gây nhầm lẫn hơn và có nghĩa là trình duyệt sẽ quan tâm đến việc gửi và cập nhật cookie của bạn (ví dụ: xem xét cách bạn có thể xử lý các phiên với thời gian chờ không hoạt động)

— Justin
nguồn

Bạn đã xem xét sự khác biệt giữa một cuộc tấn công XSS và CSRF chưa? Tôi trân trọng đề xuất rằng sử dụng cookie một mình có thể dẫn đến lỗ hổng CSRF dễ khai thác hơn so với tấn công kiểu XSS, trong khi xác thực dựa trên mã thông báo, trong khi vẫn dễ bị tổn thương, khó khai thác hơn. Dù bằng cách nào, để bảo vệ tuyệt đối trước cả hai loại tấn công, bạn cần có cả mã thông báo cookie và tiêu đề có trong yêu cầu để xem xét an toàn người dùng được xác thực và ủy quyền.

— RibaldEddie

@RibaldEddie Không tôi đã không - Tôi đoán tôi đã giả định rằng một số cơ chế khác sẽ được sử dụng để ngăn chặn CSRF. Bất kỳ cơ hội bạn có thể đi vào chi tiết hơn? Làm thế nào là xác thực dựa trên mã thông báo vẫn dễ bị tổn thương? Và làm thế nào để sử dụng cả hai phương pháp bảo vệ chống lại CSRF?

— Justin

Mẫu mã thông báo được mã hóa là một giải pháp. Vậy là gửi cookie đôi. Cả hai đều cần một giá trị khác được gửi cùng với yêu cầu khi sử dụng cookie để vượt qua thông tin đăng nhập.

— RibaldEddie

Một đọc tốt. Nó nói về việc lưu mã thông báo vào bộ nhớ cục bộ và sau đó gửi lại qua javascript trong yêu cầu http.

: https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-st Storage

— người dùng2727195
nguồn

Xin vui lòng, không chỉ liên kết đến các trang web bên ngoài để ngăn chặn thối liên kết. Nếu bài viết chứa thông tin có giá trị, cung cấp một bản tóm tắt của bài viết và đăng nó ở đây.

— Andy

Có rất nhiều thông tin có giá trị trong đó, một bản tóm tắt các điểm cao sẽ rất hay (như tận dụng việc ký JWT, sử dụng cookie và một số bước khác).

— Berin Loritsch

Tất cả các trình duyệt hiện hỗ trợ Digest Auth, bảo mật thậm chí qua HTTP. Tùy thuộc vào yêu cầu chính xác của bạn, điều này có thể là đủ.

— Hugh Morris
nguồn