Luồng OAuth2 từ máy chủ tài nguyên đến một máy chủ tài nguyên khác

Question

Thảo luận thuyết phục thực hiện.

Giả sử sơ đồ sau.

• Đường màu đen cho biết dịch vụ nào được máy chủ xác thực bảo vệ.
• dòng màu xanh lá cây thể hiện sự tương tác giữa các dịch vụ (khách hàng, và các dịch vụ đơn đặt hàng cần phải đi qua các dịch vụ dữ liệu đó sẽ truy cập vào cơ sở dữ liệu. Dịch vụ độc lập không thích các dịch vụ khác)
• đường đỏ cho thấy một yêu cầu cụ thể chảy
• Dịch vụ dữ liệu không được tiếp xúc trực tiếp với bên ngoài và chỉ có thể được truy cập bởi các dịch vụ khác được phép làm như vậy.

Tôi giả định rằng khách hàng đã nhận được mã thông báo truy cập khi người dùng xác thực với máy chủ xác thực. Luồng nào được chọn (ẩn, mã ủy quyền, mật khẩu) là không thích hợp. Tôi muốn bắt đầu thảo luận từ điểm mà khách hàng đã nhận được mã thông báo truy cập.

Từ thời điểm đó trở đi, rõ ràng với tôi điều gì sẽ xảy ra khi khách hàng cần truy cập vào một máy chủ tài nguyên đơn lẻ.

1. Make yêu cầu tài nguyên máy chủ và vượt qua mua thẻ máy chủ Resource
2. xác nhận token (không liên quan như thế nào)
3. Nếu hợp lệ, phục vụ theo yêu cầu.

Vì vậy, trong biểu đồ đó nếu khách hàng truy cập "Dịch vụ StandAlone" (không nói chuyện với bất kỳ máy chủ tài nguyên nào khác), luồng này rõ ràng đối với tôi.

Tôi gặp sự cố khi khách hàng theo đường màu đỏ trong biểu đồ. Vì vậy, tôi cần truy cập một dịch vụ (máy chủ tài nguyên) để trả lời các nhu cầu truy cập vào một dịch vụ khác (cũng là máy chủ tài nguyên). Làm thế nào để dòng chảy đi trong trường hợp đó?

Kịch bản 1.

1. "Đơn hàng dịch vụ" được thiết lập cả hai như là một máy chủ tài nguyên và là một khách hàng.
2. Khách hàng yêu cầu mã thông báo truy cập nhưng "Dịch vụ đơn đặt hàng" sẽ có một mã thông báo khác có thông tin đăng nhập của khách hàng của riêng họ để nói chuyện với "Dịch vụ dữ liệu".

Vấn đề ở đây như tôi thấy đó là tôi mất quyền người dùng. Tôi sẽ thực hiện yêu cầu đối với "Dịch vụ dữ liệu" với quyền "Dịch vụ đặt hàng" và không được phép của người dùng.

Kịch bản 2.

1. "Đơn hàng dịch vụ" được thiết lập chỉ như là một máy chủ tài nguyên.
2. khách hàng làm theo yêu cầu với người sử dụng thẻ và "dịch vụ Đơn đặt hàng" sẽ chuyển token cùng xuống đến "dịch vụ dữ liệu"

Ở đây tôi thực hiện với các điều khoản của người dùng nhưng bây giờ tôi thấy rằng tôi "dịch vụ dữ liệu "được tiếp xúc và mở cho bất kỳ dịch vụ nào khác. (Trên thực tế tôi không biết nếu OAuth2 cung cấp hạn chế như vậy. Giới hạn một khách hàng duy nhất đến các máy chủ tài nguyên cụ thể)

Kịch bản 3.

Ở đây tôi thấy một sự kết hợp của các kịch bản trên, nơi các "Đơn đặt hàng dịch vụ" sẽ cung cấp cả hai mã thông báo cho dịch vụ dữ liệu. Mã thông báo truy cập của người dùng để yêu cầu được thực hiện với quyền phù hợp và mã thông báo truy cập ứng dụng khách của "Lệnh dịch vụ" để tôi biết rằng dịch vụ được phép nói chuyện với "Dịch vụ dữ liệu".

Thực hiện

Tôi đang sử dụng khởi động mùa xuân và mùa xuân an ninh để thiết lập các thành phần OAuth2 tôi đã thấy ở trên. Tôi đã có một máy chủ auth, một máy chủ tài nguyên và một máy khách. Các khách hàng tại thời điểm này nói chuyện với một máy chủ tài nguyên mà không có yêu cầu được giao cho một máy chủ tài nguyên.

Tùy thuộc vào cách tiếp cận tốt nhất làm cách nào để tôi tiếp tục triển khai? Tôi cần phải thực hiện những thay đổi nào đối với máy chủ tài nguyên của mình để họ có thể nói chuyện an toàn với nhau?

Cảm ơn bạn đã dành thời gian

Answer 1

Bạn đang trộn khái niệm uỷ quyền và bản sắc.

vai trò oauth2 (resource owner, resource server, authorization server và client) là các vai trò và không phải là danh tính. Dịch vụ đặt hàng của bạn có vai trò resource server trong một trường hợp và vai trò client trong trường hợp khác.

Trường hợp 1 là phương pháp phù hợp.

Mã thông báo Oauth2 thực sự được gắn với một số mã định danh tài nguyên và do đó hạn chế khách hàng đến một tài nguyên cụ thể là tính năng tích hợp sẵn.

liên quan khách hàng uỷ quyền thiết lập được xử lý bằng OAuth2 scope khái niệm

Nếu bạn muốn truyền bá danh tính người dùng cuối trên một yêu cầu chảy bạn cần phải tuyên truyền một thẻ nhận dạng (ví dụ như một JWT một) trên dòng chảy (xem OIDC). Tuy nhiên nó không phải là trách nhiệm dịch vụ dữ liệu để xử lý ủy quyền người dùng cuối.

Answer 2

Từ hiểu biết của tôi, cách tiếp cận đầu tiên có vẻ đúng, theo nghĩa là "Dịch vụ đơn đặt hàng" hoạt động như một khách hàng đến máy chủ tài nguyên "Dịch vụ dữ liệu". Vì vậy, nó nên sử dụng một mã thông báo truy cập được cung cấp cho nó như là một khách hàng.

OIDC dành riêng cho khách hàng (đọc here. Cũng xem trên trang đó vì "lý do sử dụng-truy cập-tokens-to-secure-apis"), không có máy chủ tài nguyên nào sử dụng id_token đó cho bất kỳ điều gì (nhưng đó là sự thật rằng mỗi người triển khai thực hiện theo các quyết định riêng của mình về vấn đề đó để nó gây nhầm lẫn. Tôi khuyên bạn nên đọc here).

Vì vậy, từ quan điểm của tôi, chúng tôi có những lựa chọn thay thế để đạt được những gì bạn yêu cầu:

1. "Dịch vụ Đặt hàng" để hoạt động như một khách hàng với đầy đủ chức dưới nguồn "Dịch vụ dữ liệu" (hoặc ít ít nhất là 'loại tài nguyên' bạn muốn truy cập). Nếu bạn cần cung cấp cho "Dịch vụ dữ liệu" một số thông tin liên quan đến ai là người khởi tạo cho "Đơn đặt hàng dịch vụ" để yêu cầu bất cứ điều gì, thì đây là một phần của tải trọng khi yêu cầu tài nguyên (nó không phải là một phần của access_token).
2. Chủ sở hữu tài nguyên (Người dùng) trước đây đã cấp quyền truy cập cụ thể vào "Dịch vụ đơn hàng" cho tài nguyên cụ thể "Dịch vụ dữ liệu" của mình. Tương tự như điểm trước đó, nhưng "Dịch vụ đặt hàng" không có quyền truy cập vào tất cả các tài nguyên "Dịch vụ dữ liệu". Thông tin từ người khởi tạo vẫn là một phần của tải trọng.
3. Để tránh truyền thông tin khởi tạo như là một phần của tải trọng, tôi đoán chúng tôi có thể tạo thông tin đăng nhập khách hàng "theo yêu cầu" với một số trường liên quan đến chủ sở hữu tài nguyên mà họ được liên kết hoặc bằng cách nào đó trước đó người dùng tạo họ và liên kết với hồ sơ của mình để sau này có thể được truy lục bởi "Đơn đặt hàng Dịch vụ". Đó là nơi mà nó bắt đầu để có được lộn xộn để undertanding của tôi, và tài liệu không rõ ràng (OAuth2 RFC không bao gồm đó).
4. Xem toàn bộ hệ thống dưới dạng một, chỉ với một khách hàng. access_token nhận được từ máy khách phía trước (người dùng tương tác với) chứa tất cả các phạm vi cụ thể cần thiết. Cả "khách hàng", "dịch vụ đặt hàng", "dịch vụ khách hàng" chia sẻ thông tin đăng nhập của khách hàng giống nhau và chỉ chuyển tiếp "mã thông báo truy cập" từ một đến khác (do đó không phải "ủy nhiệm ứng dụng khách" nữa). Vì vậy, cả hai đều có cùng một nhóm quyền. Chủ sở hữu tài nguyên sẽ cấp các quyền đó khi đăng nhập vào máy chủ ủy quyền đầu tiên, vì vậy nó không phải là xấu. Nhưng rõ ràng điều này có nghĩa là bạn không thể tinh chỉnh quyền từ mỗi máy khách phụ và máy chủ tài nguyên sẽ không thể xác định 'môđun con' nào là yêu cầu dựa trên yêu cầu userinfo truy cập token (nếu cần, nó phải là một phần của tải trọng). điều này có ý nghĩa bảo mật cho chắc chắn.

Tôi chỉ sử dụng phương án thay thế 4 cho đến nay (dành cho mục đích mạng nội bộ). Vì vậy, không thể nói nhiều hơn về 3 khác trong thế giới thực.

Tôi chưa thấy giải thích cụ thể dựa trên 'tiêu chuẩn được chấp nhận bởi cộng đồng' về cách tiếp cận những gì bạn đã yêu cầu (và điều đó không trực tiếp mâu thuẫn).