Bảo đảm REST API của tôi với OAuth trong khi vẫn cho phép xác thực thông qua các nhà cung cấp OAuth của bên thứ ba (sử dụng DotNetOpenAuth)

Question

Tôi có một sản phẩm với API REST đơn giản để người dùng có thể tích hợp trực tiếp với các tính năng của sản phẩm mà không cần sử dụng giao diện người dùng web của tôi . Gần đây tôi đã nhận được sự quan tâm từ các bên thứ ba khác nhau về việc tích hợp các máy khách của họ với API để cho phép người dùng sản phẩm của tôi truy cập dữ liệu của họ bằng ứng dụng của bên thứ ba đó.

Tôi đã thấy rằng các ứng dụng muốn sử dụng Twitter xác thực bằng cách sử dụng trang đăng nhập được lưu trữ bởi Twitter cấp quyền ứng dụng cụ thể để truy cập dữ liệu của người dùng đó. Bạn nhấp vào nút "Cho phép" hoặc "Từ chối" và quá trình xác thực hoàn tất. Facebook sử dụng cùng một cơ chế tốt nhất mà tôi có thể nói.

Khi nghiên cứu sâu hơn, điều này có vẻ là OAuth đang hoạt động và thấy API của tôi là dựa trên Net. Tôi nghĩ mình nên sử dụng DotNetOpenAuth và cung cấp một cơ chế tương tự. Thật không may là các mẫu được ghi lại một cách thưa thớt (nếu có) và hướng dẫn duy nhất tôi có thể tìm thấy trực tuyến dường như tập trung vào việc giúp bạn cung cấp cơ chế đăng nhập cho người dùng để họ có thể đăng nhập vào trang web của bạn bằng nhà cung cấp bên thứ ba.

Điều tôi muốn thực sự là thực sự là API REST của tôi xử lý tất cả xác thực cốt lõi và logic nghiệp vụ cho ứng dụng web của tôi và dưới ứng dụng web, ứng dụng web của tôi về cơ bản là một ứng dụng khác chỉ sử dụng API qua OAuth. Người dùng sẽ xác thực trên trang web hoặc trực tiếp sử dụng tên người dùng và mật khẩu của họ hoặc thông qua nhà cung cấp bên thứ ba như MyOpenID hoặc Facebook và sau đó trang web sẽ sử dụng mã trả lại để xác thực dựa vào REST API.

Nó về cơ bản trông giống như tôi cần API của tôi bằng cách nào đó tổ chức một dịch vụ OAuth, nhưng cũng có người dùng sử dụng một dịch vụ bên thứ ba OAuth. Tôi không thể không nghĩ rằng tôi không có đủ hiểu biết về OAuth để quyết định xem tôi có quá nhiều thứ hay không, hoặc nếu những gì tôi đang cố gắng làm là một cách tốt hay xấu để làm mọi thứ.

Ai đó có thể cho tôi ít nhất một tổng quan rộng về các bước tôi cần thực hiện hoặc những gì tôi nên xem xét để thực hiện điều này? Hoặc chỉ cho tôi một số hướng dẫn? Hoặc nổ lời đề nghị của tôi và nói với tôi rằng tôi đang đi về điều này (kiến trúc) tất cả đều sai?

Answer 1

Trước tiên tôi muốn nhấn mạnh sự khác biệt giữa xác thực và ủy quyền:

Một dùng xác nhận trang web của bạn bằng cách cung cấp một số chứng chỉ như một tên người dùng + mật khẩu. OpenID cho phép điều này được di dời bằng cách yêu cầu người dùng xác thực cho một dịch vụ khác, sau đó xác nhận danh tính của người dùng cho trang web của bạn thay mặt người dùng. Trang web của bạn tin tưởng các dịch vụ của bên thứ ba (nhà cung cấp OpenID) và do đó coi người sử dụng đăng nhập

Một dịch vụ hoặc ứng dụng không xác thực để trang web của bạn -. ít nhất là không thường. Người dùng ủy quyền cho một dịch vụ hoặc ứng dụng truy cập dữ liệu của người dùng. Điều này thường được thực hiện bởi ứng dụng yêu cầu ủy quyền của nhà cung cấp dịch vụ, sau đó gửi người dùng đến nhà cung cấp dịch vụ, nơi người dùng xác thực lần đầu tiên (để nhà cung cấp dịch vụ biết người đang nói chuyện với ai) và sau đó người dùng nói với trang web "có, nó là ok cho [ứng dụng] để truy cập dữ liệu của tôi [trong một số cách hạn chế] ". Từ đó trở đi, ứng dụng sử dụng mã thông báo ủy quyền để truy cập dữ liệu người dùng trên trang web của nhà cung cấp dịch vụ. Lưu ý rằng ứng dụng không xác thực chính nó như thể nó là người dùng, nhưng nó sử dụng một mã khác để đảm bảo dịch vụ được ủy quyền truy cập dữ liệu của người dùng cụ thể.

Vì vậy, với sự phân biệt đó được làm rõ, bạn có thể đưa ra quyết định về trang web của bạn về xác thực và ủy quyền hoàn toàn độc lập. Ví dụ: nếu bạn muốn người dùng của mình có thể đăng nhập bằng tất cả: tên người dùng + mật khẩu, OpenID và Facebook, bạn có thể làm điều đó. Một quyết định hoàn toàn trực giao là cách bạn cho phép các ứng dụng (có rất nhiều giao thức bạn có thể sử dụng cho điều này, OAuth tất nhiên là khá phổ biến).

OpenID tập trung vào người dùng xác thực. OAuth được tập trung vào ứng dụng ủy quyền. Tuy nhiên, một số dịch vụ như Facebook và Twitter đã chọn sử dụng OAuth để ủy quyền xác thực và thay vì sử dụng OpenID để xác thực và OAuth để ủy quyền.

Bây giờ cho dự án của riêng bạn, tôi khuyên bạn nên kiểm tra mẫu dự án ASP.NET MVC 2 OpenID web site (C#) có sẵn từ Thư viện VS. Ngoài hộp, nó đi kèm với xác thực OpenID và hỗ trợ Nhà cung cấp dịch vụ OAuth. Điều này có nghĩa là người dùng của bạn có thể đăng nhập bằng OpenID và các ứng dụng và dịch vụ của bên thứ ba có thể sử dụng OAuth để thực hiện cuộc gọi API tới trang web của bạn và truy cập dữ liệu người dùng.

Điều gì có vẻ như bạn muốn thêm vào mẫu dự án này khi bạn bắt đầu là khả năng người dùng của bạn đăng nhập bằng tên người dùng + mật khẩu cũng như OpenID. Ngoài ra, nếu bạn muốn Facebook và Twitter là một tùy chọn cho người dùng của mình, bạn cũng phải thực hiện điều đó vì họ không sử dụng tiêu chuẩn OpenID. Tuy nhiên, việc tải xuống DotNetOpenAuth bao gồm các mẫu để đăng nhập bằng Twitter và Facebook để bạn có một số hướng dẫn tại đó.

Tôi nghi ngờ bạn sẽ không có nhiều nếu có bất kỳ điều gì cần làm ở mặt trước ủy quyền. Nó đi kèm với OAuth như tôi đã nói trước đây, và điều đó có thể sẽ đủ cho bạn.

Answer 2

Trước hết. Bạn cần phải tách biệt tinh thần API của bạn là gì - từ các phương thức xác thực.

API của bạn về cơ bản là tài nguyên và phương pháp để thao tác các tài nguyên đó. Và bạn có thể có một số phương pháp xác thực quyền truy cập vào API của bạn.

OAuth là một cơ chế xác thực như vậy. Là một nhà cung cấp OAuth là tuyệt vời, mặc dù đặc điểm kỹ thuật là một chút khó nắm bắt, đặc biệt là các bộ phận mà phải làm với chữ ký. Khi bạn có OAuth tại chỗ, ứng dụng khách thường có thời gian xác thực dễ dàng vì có rất nhiều thư viện "nguồn mở, đã thực hiện, chỉ cần triển khai" ở hầu hết các ngôn ngữ.

Ưu và khuyết điểm của OAuth đã được tranh luận trong một thời gian. Nhưng để hình thành ý kiến ​​của riêng bạn, tôi khuyên bạn nên đọc this definitive guide, written by Eran Hammer-Lahav, một trong những người chịu trách nhiệm về đặc tả OAuth.

Lựa chọn thay thế thực sự duy nhất cho OAuth theo như tôi thấy, là OAuth 2.0 và xác thực cơ bản đơn giản.

Ngoài ra, bạn đang nói về xác thực bằng cách sử dụng Open-ID, hoặc nhận dạng facebook vv Đây là một câu hỏi khác bạn cần phải tự hỏi mình. Nhưng nó thực sự nằm ngoài phạm vi của API và OAuth. Đối với tôi, điều đó cảm thấy nhiều câu hỏi về tạo người dùng trong dịch vụ của bạn. Tôi có thể sai.