2013-04-26 29 views
25

Thông số OAuth 2 dẫn tôi tin rằng "máy chủ tài nguyên" và "máy chủ ủy quyền" không nhất thiết phải là cùng một ứng dụng nhưng tôi đang cố gắng tìm ra cách này thực sự được triển khai trong thực tế.OAuth 2: tách máy chủ tài nguyên và máy chủ ủy quyền

Như một ví dụ, giả sử các ứng dụng sau đây tồn tại:

  • máy chủ tài nguyên
  • phép máy chủ
  • web frontend
  • của bên thứ ba ứng dụng client

Kịch bản # 1: Đăng nhập vào giao diện người dùng web

  • dùng gửi vào ô đăng nhập
  • ứng dụng web POSTS thông tin để auth máy chủ (grant_type = mật khẩu) và nhận được một access_token
  • các cửa hàng ứng dụng web access_token trong một phiên
  • theo từng yêu cầu tiếp theo:
    • Lấy (các) tài nguyên từ máy chủ tài nguyên (w/access_token trong tiêu đề Cấp quyền) và hiển thị tài nguyên trong giao diện web
    • nếu chúng tôi nhận được 401 rồi đăng xuất người dùng (xóa access_token khỏi phiên)

Kịch bản # 2: Ủy quyền ứng dụng của bên thứ ba

  • yêu cầu người dùng cho phép từ dịch vụ auth
  • cho phép/từ chối mẫu được hiển thị
  • dùng được chuyển hướng trở lại ứng dụng client với sự cho phép mã hiện tại
  • ứng dụng của khách hàng Gửi mã tới dịch vụ xác thực (grant_type = authorization_code) và nhận access_token
  • khách hàng Nhận tài nguyên từ máy chủ tài nguyên đang chuyển (w/Tiêu đề Auth)

Phần tôi đang gặp khó hiểu là cách xác thực người dùng trước khi hiển thị biểu mẫu cho phép/từ chối trong trường hợp # 2. Người dùng có thể đăng nhập vào ứng dụng web chính nhưng dịch vụ auth không có ý tưởng về điều đó và bằng cách nào đó sẽ cần phải xác thực lại người dùng. Dịch vụ xác thực có cần hỗ trợ đăng nhập/phiên không?

Tôi tự hỏi nếu nó có thể có ý nghĩa hơn đối với các ứng dụng web để chịu trách nhiệm về hiển thị cho phép/từ chối hình thức vì hai lý do:

  1. nó giữ tất cả các giao diện người dùng trong một ứng dụng duy nhất
  2. sẽ không buộc người dùng phải gửi lại thông tin của mình nếu họ đã đăng nhập vào ứng dụng web

Dưới đây là một khả năng thay thế cho kịch bản # 2:

  • yêu cầu người dùng cho phép từ ứng dụng web
  • cho phép/từ chối mẫu được hiển thị
  • POSTS ứng dụng web để auth máy chủ tạo ra một khoản trợ cấp mới, mã giấy phép được trả lại
  • ứng dụng web chuyển hướng đến ứng dụng client với mã uỷ quyền có mặt
  • ứng dụng khách POST mã để dịch vụ xác thực và nhận access_token

Cách tốt nhất để xử lý vấn đề này là gì? Bất kỳ ý kiến ​​chung, lời khuyên, vv sẽ là tuyệt vời!

Cảm ơn

Trả lời

2

kịch bản thay thế của bạn có lẽ là những gì bạn muốn đi với: nếu bạn thực sự thực sự muốn tách dòng của bạn ra, bạn có thể thử một cái gì đó như thế này:

  1. yêu cầu người dùng cho phép từ auth dịch vụ thay mặt cho dịch vụ với grant_type = code
  2. dịch vụ xác thực nhận ra người dùng chưa đăng nhập: chuyển hướng đến ứng dụng web với thông số yêu cầu yêu cầu máy chủ web gửi lại người dùng.
  3. thông số yêu cầu cửa hàng ứng dụng web, sau đó yêu cầu tên người dùng/mật khẩu
  4. ứng dụng web ĐĂNG thông tin đăng nhập vào máy chủ auth (grant_type = password) và nhận access_token.
  5. các cửa hàng ứng dụng web access_token trong một phiên
  6. ứng dụng web tạo ra một mã thông báo đã ký chụp id người dùng và chuyển hướng trở lại dịch vụ auth với thẻ ký như request parameter
  7. dịch vụ auth phân tích cú pháp ký thẻ, chiết xuất dùng id, màn hình cho phép/từ chối hình thức
  8. dùng được chuyển hướng trở lại ứng dụng client với mã uỷ quyền có mặt
  9. ứng dụng
  10. client POSTS mã để auth dịch vụ (grant_type = authorization_code) và nhận được một access_token
  11. client GET nguồn từ máy chủ tài nguyên đi qua (w/Auth tiêu đề)
+0

Cảm ơn! Đó là một cách tiếp cận thú vị. Vẫn không chắc chắn nếu nó có giá trị phức tạp thêm. – scttnlsn

+0

Vâng, có một câu hỏi ở đó: nếu bạn có nhiều ứng dụng web khác nhau bằng cách sử dụng cùng một phụ trợ auth (như Google không) bạn có thể muốn có một máy chủ auth chuyên dụng với tất cả các màn hình đăng nhập liên quan trên đó. Đối với một ứng dụng có thể không đáng để làm việc. – Femi

+1

Loại cấp mật khẩu chỉ nên được sử dụng cho các ứng dụng thuộc quyền sở hữu và kiểm soát của pháp nhân sở hữu dịch vụ ủy quyền. Nếu không, nó sẽ mở ra các lỗ hổng bảo mật nghiêm trọng. Người dùng chỉ nên cung cấp thông tin xác thực của họ cho ứng dụng đã cấp cho họ. – user2268788

0

OAauth2 khuôn khổ tài liệu: https://tools.ietf.org/html/rfc6749

(A) Các khách hàng yêu cầu một thẻ truy cập bằng cách chứng thực với máy chủ uỷ quyền và trình bày một cấp phép.

(B) Máy chủ ủy quyền xác thực ứng dụng khách và xác nhận cấp ủy quyền và nếu hợp lệ, hãy cấp mã thông báo truy cập và mã thông báo làm mới.

(C) Khách hàng thực hiện yêu cầu tài nguyên được bảo vệ đến tài nguyên máy chủ bằng cách trình bày mã thông báo truy cập.

(D) Máy chủ tài nguyên xác thực mã thông báo truy cập và nếu hợp lệ, sẽ đáp ứng yêu cầu.

(E) Các bước (C) và (D) lặp lại cho đến khi mã thông báo truy cập hết hạn. Nếu máy khách biết mã thông báo truy cập đã hết hạn, nó sẽ chuyển sang bước (G); nếu không, nó làm cho một yêu cầu tài nguyên được bảo vệ khác.

(F) Vì mã thông báo truy cập không hợp lệ, máy chủ tài nguyên trả lại lỗi mã thông báo không hợp lệ.

(G) Máy khách yêu cầu mã thông báo truy cập mới bằng cách xác thực với máy chủ ủy quyền và hiển thị mã thông báo làm mới. Yêu cầu xác thực khách hàng được dựa trên loại khách hàng và trên chính sách máy chủ ủy quyền.

(H) Máy chủ ủy quyền xác thực máy khách và xác nhận mã thông báo làm mới và nếu hợp lệ, hãy tạo mã thông báo truy cập mới (và, tùy chọn, mã thông báo làm mới mới).