Tôi nên kiến ​​trúc sư dịch vụ web RESTful như thế nào để sử dụng bên thứ 3 (tức là Google, Facebook, Twitter) để xác thực?

Đối với công việc của tôi, chúng tôi có một dịch vụ web RESTful tuyệt vời mà chúng tôi đã xây dựng mà chúng tôi sử dụng để điều khiển một vài trang web chúng tôi có. Về cơ bản, dịch vụ web cho phép bạn tạo và làm việc với vé hỗ trợ và trang web chịu trách nhiệm cho giao diện người dùng. Bất kỳ yêu cầu dịch vụ web nào cũng sử dụng tiêu đề xác thực mà chúng tôi sử dụng để xác thực người dùng và mật khẩu của họ cho mỗi cuộc gọi.

Năm nay chúng tôi đang tìm cách mở rộng các tùy chọn đăng nhập để người dùng trên trang web có thể đăng nhập thông qua Google, Twitter và Facebook (có thể là những người khác). Tuy nhiên, tôi gặp nhiều rắc rối khi tìm hiểu cách kiến ​​trúc này để dịch vụ web có thể sử dụng nhà cung cấp xác thực của bên thứ 3 để đảm bảo người dùng nói họ là ai. Có cách thực hành tốt nhất nào để làm điều này không?

Hiện tại chúng tôi đang nghĩ đến việc trang web tự xử lý xác thực người dùng và sau đó sử dụng lệnh gọi setSessionId mới để đăng ký phiên hiện tại của họ với phần cuối dịch vụ webservice. Mỗi yêu cầu bổ sung cho dịch vụ web sẽ chuyển qua sessionId đó và sẽ xác thực nó. Điều này có vẻ ổn, nhưng tôi có cảm giác đó ở phía sau đầu rằng tôi không nghĩ đến điều này và tất cả các diễn đàn của tôi duyệt và đọc các thông số oauth và openid chỉ khiến tôi bối rối hơn. Bất kỳ lời khuyên cho làm thế nào để giải quyết điều này?

Có vẻ như có hai mục tiêu:

1. Người dùng cuối dễ dàng xác thực với các tài khoản xã hội hiện có của họ
2. Dễ dàng cho các nhà phát triển sử dụng dịch vụ web của bạn

Việc cho phép mọi người sử dụng tài nguyên trên trang web của bạn làm cho OAuth2 trở thành một cơ chế ưa thích do tính phổ biến và tính sẵn có của các thư viện khách.

1. Người dùng cuối dễ dàng xác thực với các tài khoản xã hội hiện có của họ

Người dùng cuối truy cập trang web sử dụng API của bạn và chọn đăng nhập. Chúng được gửi đến trang đăng nhập OAuth của bạn. Trang đăng nhập của bạn hiển thị lời nhắc tên người dùng và mật khẩu bình thường cho các tài khoản được quản lý trên trang web của bạn và một bộ nút xác thực xã hội nơi họ có thể nhấp để đăng nhập thông qua một trang web như Facebook. Khi người dùng chọn Facebook, bạn chuyển hướng họ đến Facebook để phê duyệt lựa chọn (bắt đầu luồng xác thực facebook). Khi người dùng cuối hoàn thành đăng nhập tại Facebook, họ sẽ được chuyển hướng trở lại trang web của bạn.

Khi người dùng được chuyển hướng trở lại trang web của bạn từ Facebook, bạn lưu thông tin của người dùng đó vào hồ sơ người dùng trong cơ sở dữ liệu của bạn và sau đó tạo phiên mới cho người dùng đó. Bạn ngay lập tức chuyển hướng người dùng cuối đến trang web hạ nguồn ban đầu của họ với access_token oauth, hoàn thành luồng oauth ban đầu.

2. Dễ dàng cho các nhà phát triển sử dụng dịch vụ web của bạn

Nếu bạn là nhà cung cấp ủy quyền thì bạn nên tạo một giao diện đơn giản để các nhà phát triển phụ thuộc vào điều đó không thay đổi mỗi khi bạn thêm nhà cung cấp xác thực ngược dòng mới không thực hiện hoàn hảo oauth. Đây là lý do tại sao tôi tin rằng bạn nên triển khai trang web của nhà cung cấp OAuth2 và trang web đó phải là người tiêu dùng của các trang web xác thực xã hội.

Đối với nhà phát triển sử dụng API nghỉ ngơi tốt đẹp của bạn, họ sẽ không biết về tương tác của Facebook trừ khi bạn chọn cung cấp cho họ một gợi ý thông qua bài đăng chụp phiên (ví dụ).

TL; DR

Làm cho người tiêu dùng API của bạn thích bạn bằng cách triển khai OAuth2 và ẩn các phức tạp xác thực xã hội. Bạn có thể, trong dòng chảy oauth của mình cho các trang web hạ lưu của bạn, kích hoạt một luồng oauth bổ sung với facebook.

Hình ảnh vì hình ảnh == từ * 1000:

Chúng ta có thể gọi đây là oauth2-piggy-back không?

Từng bước chảy

1. Người dùng cuối truy cập trang web sử dụng API của bạn
2. Người dùng cuối được gửi đến trang web của bạn để ủy quyền hoặc đăng ký (oauth2)
3. Người dùng cuối chọn xác thực xã hội, nhấp vào nút đăng nhập facebook
4. Trang web của bạn đặt cookie hoặc đặt stateoauth trong facebook để biết người dùng đến từ đâu
5. Người dùng cuối đã chuyển hướng đến Facebook và chấp nhận kết nối tại trang facebook
6. Người dùng cuối đã chuyển hướng đến trang web của bạn để hoàn tất quá trình xác thực facebook
7. Bạn tra cứu hoặc tạo người dùng trong cơ sở dữ liệu của bạn
8. Bạn tạo một phiên mới trên máy chủ của bạn
9. Bạn chuyển hướng người dùng trở lại trang web ban đầu của họ bằng mã thông báo phiên của bạn

Làm thế nào để làm cho nó mở rộng

Trước tiên, bạn nên chú ý tất cả những người này sử dụng cùng một cơ chế để đăng nhập. Tất cả họ đều sử dụng OAuth để xác thực. Điều này bạn cần tận dụng bằng cách bắt đầu với một thư viện OAuth chung. Không sử dụng thư viện riêng của họ để xác thực, những thư viện này sẽ không thể sử dụng được cho các nhà cung cấp khác. Nếu bạn nhận được hang OAuth2, việc thêm nhiều nhà cung cấp là khá dễ dàng.

Thật không may, bạn cần hai người trong số họ, vì twitter vẫn chưa nhảy vào nhóm nhạc OAuth2.

OAuth cần bạn tạo giao diện cho bên xác thực. Các mã thông báo sẽ được trao đổi máy chủ với máy chủ. Tạo một điểm vào, có thể xử lý tất cả các giao tiếp.

Mã thông báo phải được lưu trữ trong một bảng riêng biệt từ tài khoản của bạn, điều này là do chúng có thể là nhiều mã thông báo và nhiều hồ sơ được liên kết. Một số dịch vụ cung cấp cho bạn hai mã thông báo, một trong số đó là mã thông báo làm mới.

Bây giờ bạn thiết kế một giao diện, gói gọn các chức năng khác mà bạn cần. Cá nhân tôi sẽ thiết lập một dịch vụ REST riêng cho việc này. Bằng cách này bạn có thể dễ dàng mở rộng xác thực đến những nơi khác.
Một số dịch vụ sử dụng JSON để giao tiếp, các dịch vụ khác sử dụng XML, v.v. Đối với người dùng trước, bạn cần thống nhất tất cả chúng. Đây là một quá trình khá đau đớn, nhưng có thể rút ra một số căn cứ phổ biến ở đây.

Một vấn đề khác ở đây là không phải tất cả các dịch vụ đều cung cấp cùng chức năng. Điều này có thể có nghĩa là các dịch vụ của bạn không thể cung cấp API đầy đủ như bạn đã chỉ định. Bạn cần phải có một chiến lược ở đây, để cho ứng dụng hạ cấp một cách duyên dáng.

Tất cả điều này sẽ đảm bảo bạn có thể dễ dàng thêm các nhà cung cấp bên thứ 3 mới.

Vấn đề về mã thông báo

Các mã thông báo bị giới hạn về thời gian, do đó bạn cần một vài công việc định kỳ, có thể kiểm tra xem mã thông báo có còn sử dụng được hay không, nếu không bạn phải xóa nó. Bạn cũng có thể làm mới mã thông báo theo cơ chế này.

Đôi khi xảy ra, người dùng rút lại mã thông báo. Hãy sẵn sàng cho việc này.

Lưu trữ dữ liệu

Nếu bạn có thiết kế này, bạn cần suy nghĩ về dữ liệu bạn cần. Điều này sau một phần từ giao diện vừa tạo của bạn. Thiết kế một số bảng cho điều này và xem nếu dữ liệu thực sự có thể truy xuất được. Một số dịch vụ không cho phép bạn lấy nhiều dữ liệu. Bạn cũng nên tính đến việc bạn càng cần nhiều dữ liệu, thông điệp về quyền riêng tư càng trở nên nặng nề. Vì vậy, hãy khiêm tốn trong nhu cầu của bạn, nếu không người dùng sẽ không sử dụng nó.

Để xác minh thêm, bạn có thể lưu trữ các cấu hình trong một bảng riêng biệt nhưng được liên kết với người dùng của bạn. Điều này sẽ cung cấp cho bạn nhiều thông tin hơn về ai đó.

Ngoài ra kiểm tra luật địa phương của bạn, đối với một số dữ liệu bạn cần thêm biện pháp phòng ngừa.

Điều cuối cùng Đừng phạm lỗi khi bạn không tạo tài khoản trên các dịch vụ của riêng bạn. Nếu người dùng bị cấm từ facebook, anh ta sẽ không thể đăng nhập vào dịch vụ của bạn. Đây là một tình huống bạn không muốn tạo ra. Điều này thường bị bỏ qua.

Tôi chắc chắn sẽ sử dụng giải pháp có vẻ như bạn đã tìm ra: triển khai xác thực bên thứ 3 trên trang web của khách hàng và sau đó liên kết các mã xác thực xác thực của bên thứ 3 với tài khoản người dùng trang web của bạn và sau đó kích hoạt cuộc gọi setSessionID của bạn đăng nhập.

Tùy thuộc vào kiến ​​trúc trang web của bạn, bạn có thể thấy việc sử dụng thư viện như EveryAuth hoặc Passport sẽ rất hữu ích.

Hai xu của tôi: Tôi chưa bao giờ làm bất cứ điều gì như thế này trước đây và tôi cũng không biết cơ chế đăng nhập FB, Twitter hay Google hoạt động như thế nào, nhưng một vài vấn đề xuất hiện trong đầu tôi ngay khi tôi đọc câu hỏi của bạn:

• Nhiều lần đăng nhập: Điều gì xảy ra nếu tôi đăng nhập bằng tài khoản Facebook của mình một ngày và tài khoản Google của tôi vào ngày hôm sau? Hay đồng thời? Bạn có coi hai tài khoản này là tài khoản riêng biệt, duy nhất hoặc bạn nên có một số phương pháp để liên kết hai tài khoản này và cho phép tôi truy cập vé của mình theo cách nào?
• Dựa vào số nhận dạng bên ngoài: Điều gì xảy ra khi Facebook hoặc Twitter quyết định thay đổi giao diện của số nhận dạng tài khoản của họ? Để minh họa, nếu BazLogin đại diện cho một tài khoản duy nhất sử dụng mã {4382-af56} nhưng quyết định rằng từ bây giờ các tài khoản sẽ có 12 chữ số vì 8 là không đủ, làm thế nào để bạn biết {1234-4382-af56} từ {0000-4382 -af56}?

Chúng tôi có thể giải quyết hai vấn đề này bằng cách chọn liên kết các tài khoản bên ngoài với tài khoản nội bộ, không chỉ ID phiên. Sau đó, đăng nhập bên ngoài có thể chỉ là một cổng để tạo tài khoản nội bộ. Nếu tôi xác thực bằng nhiều phương thức đăng nhập, bạn có thể cho tôi biết tôi đã đăng nhập. Nếu nhà cung cấp xác thực bên ngoài thay đổi thứ gì đó mà chúng tôi dựa vào, chúng tôi có thể yêu cầu người dùng cung cấp tên và mật khẩu của tài khoản nội bộ của họ và tạo một hiệp hội mới cho đăng nhập trong tương lai.

Tôi không chắc chắn tôi đã giải quyết các vấn đề bạn có trong đầu, nhưng bạn không thực sự đề cập đến bất kỳ mối quan tâm cụ thể nào. Tôi hy vọng câu trả lời của tôi là hữu ích, dù bằng cách nào.