Các mẫu doanh nghiệp để xác thực JWT cho ứng dụng dựa trên REST?

Đặc tả JWT chỉ mô tả tải trọng và cách gửi, nhưng để giao thức xác thực mở, cho phép tính linh hoạt, nhưng thật không may, tính linh hoạt có thể dẫn đến phản xạ và xác định sai.

Tôi đang tìm kiếm một số doanh nghiệp đã suy nghĩ kỹ và thử nghiệm xác thực JWT, mà tôi có thể sử dụng hoặc điều chỉnh, nhưng tôi đã thất bại trong việc tìm kiếm thứ gì đó hoàn chỉnh.

Những gì tôi đã nghĩ là:

• khi không có tiêu đề ủy quyền nào được đáp ứng hoặc mã thông báo JWT không hợp lệ hoặc hết hạn, hãy gửi HTTP 401
• để xác thực, sử dụng / đăng nhập kênh REST, gửi tên người dùng và mật khẩu làm đối tượng JSON
• để giữ cho mã thông báo tồn tại, hãy sử dụng / giữ kênh REST, gọi nó sau mỗi N (5) phút, nhận mã thông báo JWT mới và thay thế mã hiện có sau mỗi cuộc gọi (mã thông báo hết hạn sau M (15) phút)

Tuy nhiên, điều làm tôi băn khoăn, đó là sự cần thiết của kênh / Keepalive đó. Mặt khác, nó buộc tôi phải ngăn chặn việc xác thực hết hạn, ngay cả khi người dùng đi vắng (quyết định, nếu chúng tôi muốn giữ lại chưa được đáp ứng) và tất nhiên, đó là những cuộc gọi thêm và phức tạp thêm cho giao thức. Điều thú vị là máy chủ sẽ tự động kéo dài mã thông báo. Trong môi trường dựa trên phiên, điều này xảy ra bằng cách đặt lại dấu thời gian, tuy nhiên, ở đây, máy chủ sẽ phải gửi mã thông báo mới, có thể không phải mỗi lần, nhưng một khi mã thông báo sẽ hết hạn sau R (giả sử là 10) phút. Nhưng đặt nó trong phần thân phản hồi có nghĩa là sửa đổi giao thức phản hồi JSON (do đó, giải pháp là xâm lấn và không minh bạch) và đặt một tiêu đề HTTP bổ sung mà máy khách có thể xử lý không nhất thiết phải là một mẫu tốt. TÔI'

Có mẫu doanh nghiệp nào sẵn sàng trả lời các điểm mở của tôi không? Là dự thảo giao thức của tôi là một ý tưởng đáng tin cậy? Tôi muốn sử dụng một cái gì đó sẵn sàng hơn là thiết kế từ đầu.

JWT ( Giới thiệu về mã thông báo web JSON ) chỉ là một định dạng mã thông báo, xác thực đó là một cái gì đó hoàn toàn nằm ngoài phạm vi của đặc tả đó. Nó thực sự được sử dụng phổ biến trong các hệ thống xác thực, nhưng bạn cũng có thể sử dụng nó cho các tình huống hoàn toàn khác nhau để không bao gồm các ràng buộc xác thực cụ thể trong đặc tả đó.

Nếu bạn đang tìm kiếm hướng dẫn về xác thực, bạn nên tham khảo nhóm thông số kỹ thuật OpenID Connect . Ngoài ra, nếu hệ thống của bạn bao gồm API HTTP và bạn quan tâm đến việc cung cấp quyền truy cập được ủy quyền cho các API đó cho ứng dụng khách của riêng bạn hoặc của bên thứ ba thì bạn nên tham khảo thông số kỹ thuật OAuth 2.0 .

Có các giao thức liên quan đến xác thực bổ sung như SAML và Liên kết WS vẫn được sử dụng rộng rãi trong các kịch bản doanh nghiệp, nhưng chúng phức tạp hơn đáng kể để thực hiện.

Về các điểm mở cụ thể của bạn:

• Lược đồ xác thực mã thông báo mang được xác định trong RFC 6750 chứa các hướng dẫn về cách thực hiện các yêu cầu và mã lỗi có thể .
• OAuth2 và OpenID Kết nối cả hai đều dự tính khả năng và xác định cách trao đổi tên người dùng / mật khẩu bằng mã thông báo.
• Vấn đề kéo dài vòng đời mã thông báo khép kín / theo giá trị (JWT) được giải quyết trong OpenID Connect và OAuth2 thông qua các phương tiện làm mới mã thông báo .

Mặc dù OAuth2 và OpenID Connect có thể được xem là dễ thực hiện hơn so với một số người tiền nhiệm của nó, chúng vẫn đủ phức tạp để đảm bảo một số thận trọng và chỉ thực hiện chúng nếu bạn sẵn sàng dành một lượng thời gian và tài nguyên đáng kể. Nói chung, đó là một lựa chọn tốt hơn để sử dụng các thư viện hoặc dịch vụ của bên thứ ba thực hiện công việc nặng nhọc đó cho bạn.

Cuối cùng, các giao thức này bao gồm rất nhiều tình huống để chúng có thể bị quá mức trong một số tình huống.

Tôi không nghĩ rằng bạn cần một kênh cố định. Tải trọng của bạn có thể (và được khuyến nghị) chứa thông tin hết hạn do máy chủ cung cấp (trong expkhóa, theo tiêu chuẩn ) khi mã thông báo được tạo khi đăng nhập. Nếu mã thông báo đã hết hạn được sử dụng (rõ ràng là do máy chủ xác định, chỉ tin tưởng những gì trong mã thông báo nếu chữ ký xác thực), máy chủ chỉ cần từ chối nó bằng HTTP 401, khiến máy khách xác thực lại.

Khách hàng, trong khi đó, có thể là người chủ động. Phần tải trọng không được mã hóa và vì khách hàng có thể đọc nó, nên khách hàng có thể xác định khi nào một yêu cầu sẽ được gửi với một mã thông báo đã hết hạn và do đó gọi /loginlại nếu mã thông báo đã hết hạn.

Ngoài ra, REST cho phép thông tin hypermedia được gửi dưới dạng 'công cụ trạng thái', và vì vậy nếu bạn muốn, bạn thực sự có thể thực hiện chỉ sử dụng một lần của JWT và cũng hết hạn. Sau đó, mọi yêu cầu sẽ tạo ra một JWT mới được trả về trong phản hồi cho máy khách, trong nội dung hoặc nhiều khả năng trong tiêu đề phản hồi, như hapi-auth-jwt2 thực hiện.