Cách sử dụng OAuth2 để triển khai đăng nhập/đăng ký của bên thứ ba?

Question

Đây là kế hoạch của tôi (luồng mã ủy quyền) của việc triển khai logic đăng nhập/đăng ký đó. (Các bên thứ ba chỉ được cung cấp API OAuth2)

Đầu tiên là frontend SPA sẽ gửi một yêu cầu GET đến bên thứ ba

GET https://www.example.com/oauth2 
client_id=dummyclient 
redirect_uri=https://mysite/callback 
response_type=code 
scope=openid 

Sau đó, nếu người dùng đồng ý để cung cấp cho anh/openid cô mysite sau đó fronend sẽ nhận được phản hồi HTTP 301.

---> 301 https://mysite/callback?code=dummycode 

Sau đó trình duyệt sẽ chuyển hướng trang để mysite/callback và nó sẽ tải lại SPA và vạch trần các mã trong URL mà có thể được chụp bởi các SPA sau đó nó sẽ gửi mã để gọi lại backend thực.

GET https://mysite/api/real-callback?code=dummycode 

Khi chương trình phụ trợ nhận mã, mã sẽ gửi mã cho bên thứ ba để trao đổi access_token. Khi chương trình phụ trợ nhận được access_token, nó sẽ kích hoạt yêu cầu API để có được openid của người dùng sau đó quyết định có cho phép người dùng đăng nhập hoặc đăng ký làm người dùng mới hay không. Cuối cùng, nó sẽ trả lại phản hồi HTTP cho lối vào SPA của chúng tôi chứa số access_token trong số hệ thống OAuth2 hoặc 401 phản hồi trái phép của tôi.

Vì vậy, câu hỏi của tôi là làm thế nào để chứng minh rằng callback thực được gọi bởi khách hàng của riêng tôi (Bởi vì nếu một số kẻ tấn công có được lối vào của tôi nhúng client_id sau đó ông có thể giả mạo yêu cầu OAuth2 và lừa đảo người sử dụng đồng ý. Sau đó Cuối cùng, anh ta sẽ nhận được mã số access_token của người dùng trong hệ thống của tôi.) Làm cách nào tôi có thể sử dụng OAuth2 để xác thực mà không có người dùng cuối cung cấp thêm thông tin như mật khẩu.

Answer 1

Tôi khuyên bạn nên thay đổi luồng OAuth2 thành Ẩn và yêu cầu cả access_token và id_token (Kết nối OpenID). SPA của bạn sẽ nhận được mã thông báo, gửi mã thông báo ID đến chương trình phụ trợ của bạn, có thể sử dụng mã thông báo đó để quyết định xem có thể tạo người dùng đó hay không. SPA có thể sử dụng mã thông báo truy cập để gọi các tài nguyên được bảo vệ.

Bằng cách này,

• chỉ SPA sẽ là một khách hàng OAuth2 - thẻ sẽ không được sử dụng bởi hai ứng dụng (SPA và backend),
• bạn sẽ chỉ có một chuyển hướng URI,
• bạn sẽ không cần phải chuyển mã thông báo từ backend sang SPA.

Cập nhật: Nếu không có OpenID Connect

Nếu bạn không thể sử dụng id_token, bạn có thể gửi access_token để phụ trợ của bạn và backend có thể được cung cấp tên của người dùng bằng cách gửi vào mã thông báo đến các thiết bị đầu cuối Mẫn https://tools.ietf.org/html/rfc7662 (từ phản hồi username thuộc tính). Thuộc tính username là tùy chọn. Máy chủ OAuth2 của bạn có thể trả lại nhiều thông tin hơn (chẳng hạn như tên và email).

Điểm cuối Introspection này yêu cầu xác thực, do đó, để sử dụng nó, phụ trợ của bạn sẽ phải là ứng dụng khách OAuth2 đã đăng ký với client_id và bí mật của riêng mình.