2014-10-15 16 views
5

Chúng tôi có ứng dụng web thông thường với xác thực dựa trên cookie và giờ chúng tôi muốn tách giao diện người dùng và phụ trợ (api) để có API công khai của bên thứ ba. Vì vậy, chương trình phụ trợ của chúng tôi sẽ nằm trên một miền và giao diện người dùng trên một miền khác.OAuth/OpenID dựa trên trình duyệt với thông tin đăng nhập liên tục

Để ủy quyền, chúng tôi muốn chuyển đổi cho OAuth 2 with JWT. Trong trường hợp này ứng dụng front-end của chúng tôi sẽ phải sử dụng access_token thay vì phiên cookie và nó mang lại một câu hỏi lớn cũ:

Làm thế nào để vẫn đăng nhập - khét tiếng "Remember Me" Checkbox (phần II từ Form based authentication for websites)

Từ quan điểm OAuth2, ứng dụng giao diện người dùng của chúng tôi sẽ sử dụng thứ gì đó giữa Resource Owner Password Credentials GrantImplicit Grant. Nó gần hơn với Thông tin xác thực mật khẩu cấp vì chúng tôi vẫn sẽ sử dụng biểu mẫu đăng nhập thông thường và sẽ không chuyển hướng người dùng đến một miền khác để đăng nhập. Đồng thời nó gần hơn với Ngụ ý tài trợ vì tất cả sẽ chỉ dành cho trình duyệt & JavaScript dựa trên khi access_token sẽ được lưu trong trình duyệt.

Các RFC says máy chủ uỷ quyền PHẢI KHÔNG phát hành một thẻ refresh nếu bạn sử dụng Implicit Grant và câu hỏi của tôi là nếu nó vẫn còn hợp lệ trong trường hợp này sử dụng khi bạn không thực sự sử dụng một OAuth bên 3-d nhưng bạn api của riêng? Theo bản năng, tôi cảm thấy rằng có refresh_token trong trình duyệt là lỗ hổng bảo mật và muốn xác nhận với bạn, nhưng refresh_token có vẻ là cách duy nhất để đăng nhập liên tục hoạt động giống như cách chúng tôi có với cookie.


UPD sau khi bình luận @FlorentMorselli:

Các OpenID thông số kỹ thuật vẫn không trả lời câu hỏi của tôi nếu tôi có thể sử dụng refresh_token với trình duyệt ứng dụng duy nhất

  • Google says họ cung cấp refresh_token chỉ cho access_type=offline
  • OpenID Connect Core says bạn không thể sử dụng Mã thông báo làm mới với Dòng chảy ngầm định
  • OpenI D Connect Lõi says gì về việc sử dụng refresh_token với lai luồng
  • Chỉ có one place nơi nó nói cái gì hứa hẹn về refresh_token với dòng Hybrid, nhưng không chính xác

UPD2 nhờ @reallifelolcat

Dường như OpenID Connect không hỗ trợ rõ ràng Resource Owner Password Credentials Grant, có nghĩa là bạn phải chuyển hướng người dùng tới máy chủ OpenID Connect để thực hiện đăng nhập. Bạn có biết liệu có cách nào khác để xác thực với thông tin xác thực người dùng qua OAuth 2.0 không?


Tôi tin api tách và frontend ngày càng phổ biến hơn những ngày này và tôi muốn đánh giá cao nếu bạn chia sẻ cách bạn giải quyết Persistent Đăng nhập vấn đề này và nếu bạn thả nó hoàn toàn và lực lượng người sử dụng để đăng nhập lại mỗi tuần X.

Cảm ơn!

+1

OAuth2 không phải là giao thức xác thực, đây là giao thức ủy quyền. Nếu bạn muốn xác thực người dùng bằng OAuth2 và JWT, tôi khuyên bạn nên xem [Thông số kỹ thuật của OpenID Connect] (http://openid.net/connect/) –

+0

@FlorentMorselli cảm ơn bạn đã liên kết, tôi đã mở rộng câu hỏi –

+0

Ứng dụng dựa trên tác nhân người dùng là các ứng dụng khách công khai và chúng không có khả năng lưu trữ thông tin xác thực và mã thông báo làm mới của chúng. Đó là lý do tại sao những khách hàng này không thể phát hành mã thông báo làm mới. Ứng dụng gốc (ví dụ: ứng dụng Android) cung cấp "mức độ bảo vệ có thể chấp nhận". Đó là lý do tại sao họ có thể được phép nhận mã thông báo truy cập (xem https://tools.ietf.org/html/rfc6749#section-2.1). –

Trả lời

4

Mã thông báo truy cập và mã thông báo làm mới không có liên quan gì với đăng nhập bằng Kết nối OpenID. Đây chỉ là để cho phép truy cập vào thông tin hồ sơ người dùng và cho các cuộc gọi dịch vụ có thể được xác thực tới API công khai của bạn sau khi đăng nhập. Tham khảo thông số kỹ thuật cho sự khác biệt giữa Mã thông báo ID và Mã thông báo truy cập.

Nếu bạn định sử dụng OpenID Connect để đăng nhập, sau đó từ những gì bạn đã viết cho đến nay, có vẻ như bạn cần lưu trữ Nhà cung cấp OpenID của riêng mình (OP) vì bạn muốn tránh chuyển sang một tên miền khác để đăng nhập trong:.

chúng tôi vẫn sẽ sử dụng hình thức đăng nhập bình thường và sẽ không chuyển hướng người dùng đến tên miền khác để đăng nhập vào

Nếu bạn muốn trở thành nhà cung cấp danh tính của riêng bạn, sức mạnh sau đó thêm cho bạn. Điều này có nghĩa là bạn sẽ phải triển khai cá thể làm việc của riêng bạn của một máy chủ OpenID Connect, hoàn thành với các điểm cuối ủy quyền và mã thông báo.

Bây giờ, đây là phần đăng nhập liên tục của bạn. Trình duyệt webapp của bạn sẽ là một bên dựa vào máy chủ OP mà bạn hiện có. Khi người dùng cố gắng đăng nhập vào ứng dụng trình duyệt của bạn bằng cách sử dụng OpenID Connect, họ sẽ cần phải xác thực mình với máy chủ OP của bạn. Đi qua luồng OIDC, ứng dụng trình duyệt của bạn sẽ nhận được mã thông báo ID chứa cặp tổ chức phát hành/chủ đề xác định người dùng.

Đó là tùy thuộc vào bạn để xác định cách thức người dùng lưu lại đăng nhập vào máy chủ OP của bạn, nhưng miễn là người sử dụng ít nhất là cho phép các ứng dụng trình duyệt một lần: http://openid.net/specs/openid-connect-core-1_0.html#Consent sau đó bạn có thể tiết kiệm được sự đồng ý mà cho tất cả các yêu cầu trong tương lai bằng trình duyệt này ứng dụng để đăng nhập và do đó duy trì đăng nhập liên tục.

Bạn sẽ phải cân nhắc cách bạn sẽ xử lý việc quản lý phiên, nhưng có vẻ như bạn đã có một số cookie để bạn có thể sử dụng (xem câu trả lời này: OpenID sign in mechanism - Stay signed in). Nếu không, bạn sẽ kết thúc với một tình huống mà webapp trình duyệt của bạn có để có được một mã thông báo id mới tất cả các thời gian.

Cũng như Florent đã đề cập, có những cân nhắc về bảo mật mà bạn nên cân nhắc khi thực hiện một điều khách hàng công khai mà trình duyệt web dựa trên trình duyệt của bạn sẽ là. Ví dụ: https://tools.ietf.org/html/rfc6749#section-10.16

+0

cảm ơn rất nhiều câu trả lời của bạn, theo các liên kết của bạn tôi có thể tìm thấy các thông số kỹ thuật [Yêu cầu ngay lập tức] (http://openid.net/specs/openid-authentication-2_0.html#anchor28) có vẻ đầy hứa hẹn, nhưng không phải trong OpenID Connect vì một lý do nào đó. Bạn có biết nếu nó được gỡ bỏ? Ngoài ra bây giờ tôi [thấy rằng] (http://stackoverflow.com/a/24050911/1224211) OpenID Connect [không hỗ trợ] (http://lists.openid.net/pipermail/openid-specs-ab/Week- của-Mon-20130128/002981.html) Thông tin đăng nhập mật khẩu chủ sở hữu tài nguyên Grant. –

+0

Có vẻ như quá phức tạp đối với trường hợp sử dụng đơn giản như vậy. OAuth không cho phép bạn thực hiện xác thực, OpenID buộc bạn chuyển hướng người dùng đến nhà cung cấp OpenID. Khó để tìm ra thông số cụ thể để theo dõi –

+0

Liên kết đầu tiên đó là từ OpenID 2.0 (hiện đã lỗi thời). Nó không phải là nó _removed_; OpenID Connect đơn giản! = OpenID 2.0. OIDC thậm chí không phải là một "OpenID 3.0", và nếu bạn không biết điều đó có nghĩa là gì, có vẻ như bạn có một số googling để làm. Đối với lý do tại sao những luồng khác không có trong đặc tả OIDC, hãy nhớ rằng OIDC là giao thức xác thực và xem biểu đồ này [Cấp quyền quản trị khách hàng OAuth] (https://tools.ietf.org/html/rfc6749#section -4.4). Hãy tự hỏi: Việc xác thực khi người dùng thậm chí không ở trong hình ảnh có nghĩa là gì? (gợi ý: Bạn đang làm sai). – reallifelolcat

Các vấn đề liên quan