Có nên đưa quyền truy cập và vai trò vào tải trọng của JWT không?


9

Có nên đưa thông tin về các quyền và vai trò của khách hàng vào JWT không?

Có thông tin như vậy trong mã thông báo JWT sẽ rất hữu ích vì mỗi khi có mã thông báo hợp lệ, sẽ dễ dàng trích xuất thông tin về sự cho phép về người dùng và sẽ không cần phải gọi cơ sở dữ liệu cho cùng. Nhưng bao gồm thông tin như vậy và không kiểm tra hai lần giống nhau trong cơ sở dữ liệu sẽ là một vấn đề bảo mật?

Hoặc là,

Thông tin như thông tin được đề cập ở trên không phải là một phần của JWT và chỉ nên sử dụng cơ sở dữ liệu để kiểm tra vai trò truy cập và quyền của người dùng?

Câu trả lời:


7

Mục đích bao gồm các khiếu nại trong mã thông báo là vì vậy bạn không cần phải có sự liên lạc đó giữa tài nguyên và nhà cung cấp xác thực.

Tài nguyên chỉ có thể kiểm tra mã thông báo có chữ ký hợp lệ và tin tưởng vào nội dung.

Giả sử khóa riêng là riêng tư đối với máy chủ xác thực thì bạn tốt. Một số nhà cung cấp thay đổi chìa khóa của họ xung quanh để giảm thiểu rủi ro.

Nếu bạn nghĩ về nó, nếu tài nguyên thực hiện cuộc gọi trở lại máy chủ xác thực để nhận các khiếu nại. Sau đó, về cơ bản là đảm bảo rằng nó nói chuyện với đúng máy chủ bằng các phương thức tin cậy tương tự.


Vâng cảm ơn vì một câu trả lời hay, tôi có thể biết thêm về ý của bạn từ câu nói của bạn "Một số nhà cung cấp thay đổi chìa khóa của họ xung quanh để giảm thiểu rủi ro." ?
Anshul Sahni

1
Vì vậy, thay vì có một khóa ký cố định, nhà cung cấp xác thực sẽ thay đổi nó thường xuyên và cung cấp một điểm cuối cho các máy chủ tài nguyên để tải xuống một nửa công khai của nó. Các tài nguyên phải thực hiện các cuộc gọi đến máy chủ xác thực thường xuyên, nhưng không phải một lần cho mỗi yêu cầu
Ewan

Vì vậy, tất cả các mã thông báo không hợp lệ mỗi khi chữ ký khóa được thay đổi bởi dịch vụ
Anshul Sahni

1
thông thường họ sẽ có nhiều hơn một khóa có thể, để mã thông báo trong chuyến bay sẽ không bị vô hiệu. mã thông báo sẽ chứa 'id khóa' để cho biết tài nguyên nào sẽ được sử dụng
Ewan

Điều duy nhất tôi nhớ ở đây là cách tiến hành khi dữ liệu trong JWT bị vô hiệu. Giả sử các vai trò đã thay đổi ở phía máy chủ nhưng máy khách vẫn giữ mã thông báo với tất cả các bộ vai trò. Bạn phải có thể thu hồi mã thông báo ở phía máy chủ để những mã thông báo lưu giữ thông tin lỗi thời không còn hợp lệ và có thể sử dụng cho các yêu cầu tiếp theo. Điều này phù hợp với những gì Ewans đang đề xuất bằng cách nào đó (cho phép máy chủ thu hồi mã thông báo) vì một hoặc một lý do khác.
Laiv

1

Theo kinh nghiệm của tôi, nếu tất cả các hệ thống của bạn đang sử dụng một số cơ sở dữ liệu quyền và vai trò trung tâm, bạn có thể thêm tất cả vào hệ thống JWT.

Tuy nhiên, cách tiếp cận này có thể không hoạt động tốt trong các kịch bản SSO khi bản thân máy chủ xác thực không biết gì về hệ thống đích sẽ nhận và tin tưởng mã thông báo.

Vai trò và quyền của người dùng hoàn toàn phụ thuộc vào người nhận mã thông báo JWT. Điều này đặc biệt đúng khi bạn tích hợp SSO auth với JWT vào một số hệ thống cũ đã có sẵn hệ thống con cấp phép của họ và do đó họ chỉ cần một yêu cầu để có mặt trong JWT - yêu cầu nhận dạng người dùng.


Tôi đồng ý về điều này. Quyền của người dùng không nên là một phần của jwt đặc biệt trong SSO vì idp không biết về những dịch vụ khác mà người dùng này sẽ nói với .. thay vào đó, tài nguyên nên triển khai phần ủy quyền khi danh tính đã được xác nhận cho người dùng
Manish Rawat

Tôi cũng đồng ý rằng các khiếu nại cấp phép trong JWT không phải là một ý tưởng hay ngoài API nguyên khối đơn giản. Tôi đã viết một bài đăng trên blog về nó: sdoxsee.github.io/blog/2020/01/06/ tôn
sdoxsee
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.