Bảo vệ API REST của tôi bằng 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)

Tôi có một sản phẩm có API REST đơn giản để người dùng sản phẩm 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 để bàn 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 cho ứ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ơ chế tương tự như tốt nhất tôi có thể nói.

Sau khi nghiên cứu sâu hơn, đây dường như là OAuth đang hoạt động và khi thấy API của tôi dựa trên .Net, tôi nghĩ rằng tôi nên sử dụng DotNetOpenAuth và cung cấp một cơ chế tương tự. Thật không may, các mẫu được ghi lại một cách thưa thớt (nếu có) và các 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 thực sự muốn làm là để API REST của tôi xử lý tất cả các xác thực cốt lõi và logic nghiệp vụ cho ứng dụng web của tôi và về cơ bản, ứ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 thông qua OAuth. Người dùng sẽ xác thực trực tiếp trên trang web bằ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ã thông báo được trả lại để xác thực với API REST.

Về cơ bản, có vẻ như tôi cần API của mình để lưu trữ dịch vụ OAuth bằng cách nào đó, nhưng cũng có người dùng sử dụng dịch vụ OAuth của bên thứ ba. Tôi không thể không nghĩ rằng tôi không đủ hiểu biết về OAuth để quyết định xem liệu tôi có đang làm quá nhiều việc hay không, 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 cái nhìn tổng quan về các bước tôi cần phải 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ổ tung đề xuất của tôi và nói với tôi rằng tôi đang đi về điều này (về mặt kiến ​​trúc) tất cả đều sai?

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 người dùng xác thực trang web của bạn bằng cách cung cấp một số thông tin xác thực như tên người dùng + mật khẩu. OpenID cho phép thay thế điều này bằng cách người dùng xác thực với dịch vụ khác, sau đó xác nhận danh tính người dùng với trang web của bạn thay mặt người dùng. Trang web của bạn tin tưởng dịch vụ của bên thứ ba (Nhà cung cấp OpenID) và do đó xem xét người dùng đã đăng nhập.

Một dịch vụ hoặc ứng dụng không xác thực với trang web của bạn - ít nhất là không điển hình. Người dùng cho phép 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 trước (để nhà cung cấp dịch vụ biết ai đang nói chuyện với họ) và sau đó người dùng nói với trang web "có, [ứng dụng] có thể truy cập dữ liệu của tôi [theo một cách hạn chế nào đó] ". 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 tự xác thực như thể đó là người dùng, nhưng nó sử dụng một mã khác để đảm bảo dịch vụ được phép truy cập dữ liệu của một người dùng cụ thể.

Vì vậy, với sự khác biệt đó được làm rõ, bạn có thể đưa ra quyết định trên trang web của mình về xác thực và ủy quyền hoàn toàn độc lập. Chẳng hạn, 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 ủy quyền cho các ứng dụng (có nhiều giao thức bạn có thể sử dụng cho việc này, tất nhiên OAuth khá phổ biến).

OpenID tập trung vào xác thực người dùng . OAuth tập trung vào ủy quyền ứng dụng . Tuy nhiên, một số dịch vụ như Facebook và Twitter đã chọn sử dụng OAuth để xác thực và ủy quyền 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 thực sự khuyên bạn nên kiểm tra mẫu dự án trang web (C #) ASP.NET MVC 2 có sẵn từ Thư viện VS. Ra khỏ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ứ 3 có thể sử dụng OAuth để thực hiện các cuộc gọi API đến trang web của bạn và truy cập dữ liệu người dùng.

Nghe 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 trở thành 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. Nhưng bản 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 nghi ngờ bạn sẽ không có nhiều thứ nếu làm bất cứ điều gì trên mặt trận ủy quyền. Nó đi kèm với OAuth như tôi đã nói trước đây, và điều đó có lẽ sẽ đủ cho bạn.

Đầu tiên. Bạn cần tách biệt về mặt tinh thần API của bạn - 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 thức để thao túng những 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 mình.

OAuth là một cơ chế xác thực như vậy. Trở thành một nhà cung cấp OAuth là điều tuyệt vời, mặc dù đặc điểm kỹ thuật hơi khó nắm bắt, đặc biệt là các phần phải làm với chữ ký. Khi bạn đã có OAuth, các ứ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ở, đã hoàn thành, chỉ cần triển khai" có sẵn trong hầu hết các ngôn ngữ.

Những ưu và nhược đ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 hướng dẫn dứt khoát này, được viết bởi Eran Hammer-Lahav , một trong những người chịu trách nhiệm về đặc tả kỹ thuật của OAuth.

Các 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à chỉ cần xác thực cơ bản đơn giản.

Ngoài ra, bạn đang nói về việc xác thực bằng cách sử dụng Open-ID hoặc danh tính facebook, v.v ... Đây là một câu hỏi khác bạn cần 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 hơn về một câu hỏi về việc tạo người dùng trong dịch vụ của bạn. Tôi có thể sai.