Zabezpieczanie mojego REST API za pomocą OAuth, jednocześnie zezwalając na uwierzytelnianie za pośrednictwem zewnętrznych dostawców OAuth (przy użyciu DotNetOpenAuth)

Mam produkt z prostym interfejsem API REST, dzięki czemu użytkownicy produktu mogą bezpośrednio integrować się z funkcjami produktu bez korzystania z mojego internetowego interfejsu użytkownika.

Ostatnio różne strony trzecie interesowały się integracją ich klientów na komputery stacjonarne z interfejsem API, aby umożliwić użytkownikom mojego produktu dostęp do ich danych za pomocą tej aplikacji innej firmy.

Widziałem, że aplikacje, które chcą używać Twittera, uwierzytelniają się za pomocą strony logowania hostowanej przez Twittera, która przyznaje określonej aplikacji uprawnienia dostępu do danych tego użytkownika. Klikasz przycisk „Zezwól” lub „Odmów”, a proces uwierzytelniania jest zakończony. Facebook używa tego samego mechanizmu, co mogę powiedzieć.

Po dalszych badaniach wydaje się, że jest to OAuth w akcji, a ponieważ moje API jest oparte na .Net, myślę, że powinienem użyć DotNetOpenAuth i zapewnić podobny mechanizm. Niestety przykłady są skąpo udokumentowane (jeśli w ogóle), a jedyne samouczki, które mogę znaleźć w Internecie, wydają się skupiać na pomocy w zapewnieniu mechanizmu logowania dla użytkowników, aby mogli zalogować się do Twojej witryny za pomocą dostawcy zewnętrznego.

To, co naprawdę chciałbym zrobić, to aby mój REST API obsługiwał wszystkie podstawowe uwierzytelnianie i logikę biznesową dla mojej aplikacji internetowej, a moja aplikacja internetowa była w zasadzie kolejną aplikacją, która po prostu korzysta z API za pośrednictwem OAuth. Użytkownicy uwierzytelnialiby się na stronie internetowej albo bezpośrednio, używając swojej nazwy użytkownika i hasła, albo za pośrednictwem dostawcy zewnętrznego, takiego jak MyOpenID lub Facebook, a następnie witryna w jakiś sposób użyłaby zwróconego tokenu do uwierzytelnienia w REST API.

Zasadniczo wygląda na to, że potrzebuję mojego interfejsu API, aby w jakiś sposób hostować usługę OAuth, ale także chcę, aby użytkownicy korzystali z usługi OAuth innej firmy. Nie mogę pomóc, ale myślę, że nie mam wystarczającej znajomości protokołu OAuth, aby zdecydować, czy zbytnio komplikuję, czy to, co próbuję zrobić, jest dobrym lub złym sposobem na zrobienie czegoś.

Czy ktoś może mi dać przynajmniej ogólny przegląd kroków, które muszę podjąć, lub na co powinienem zwrócić uwagę, aby to się stało? Albo wskaż mi jakieś samouczki? Albo wysadź moją propozycję i powiedz mi, że robię to (architektonicznie) źle?

Najpierw chciałbym podkreślić różnicę między uwierzytelnianiem a autoryzacją:

A użytkownik uwierzytelnia do witryny internetowej poprzez dostarczanie niektórych poświadczeń, takich jak nazwa użytkownika + hasło. OpenID pozwala na zastąpienie go poprzez uwierzytelnienie użytkownika w innej usłudze, która następnie potwierdza tożsamość użytkownika w Twojej witrynie internetowej w imieniu użytkownika. Twoja witryna ufa usłudze innej firmy (dostawcy OpenID) i dlatego uważa, że ​​użytkownik jest zalogowany.

Usługa lub aplikacja nie uwierzytelniać na swojej stronie internetowej - przynajmniej nie zwykle. Użytkownik upoważnia usługę lub aplikację do uzyskiwania dostępu do danych użytkownika. Odbywa się to zazwyczaj przez aplikację żądającą autoryzacji dostawcy usług, a następnie wysyłającą użytkownika do usługodawcy, gdzie użytkownik najpierw uwierzytelnia się (aby usługodawca wiedział, z kim rozmawia), a następnie użytkownik mówi do witryny „tak, [aplikacja] może uzyskać dostęp do moich danych [w pewien ograniczony sposób] ”. Od tego momentu aplikacja korzysta z tokena autoryzacyjnegodostęp do danych użytkownika na stronie usługodawcy. Należy zauważyć, że aplikacja nie uwierzytelnia się tak, jakby to był użytkownik, ale używa innego kodu, aby zapewnić usłudze, że ma uprawnienia dostępu do danych konkretnego użytkownika.

Po doprecyzowaniu tego rozróżnienia możesz podejmować w swojej witrynie decyzje dotyczące uwierzytelniania i autoryzacji całkowicie niezależnie. Na przykład, jeśli chcesz, aby Twoi użytkownicy mogli logować się za pomocą wszystkich: nazwa użytkownika + hasło, OpenID i Facebook, możesz to zrobić. Całkowicie ortogonalna decyzja dotyczy tego, jak autoryzujesz aplikacje (istnieje wiele protokołów, których możesz do tego użyć, oczywiście OAuth jest dość popularny).

OpenID koncentruje się na uwierzytelnianiu użytkowników . OAuth koncentruje się na autoryzacji aplikacji . Jednak kilka usług, takich jak Facebook i Twitter, zdecydowało się na użycie OAuth do uwierzytelniania i autoryzacji zamiast używania OpenID do uwierzytelniania i OAuth do autoryzacji.

Jeśli chodzi o Twój własny projekt, zdecydowanie zalecamy zapoznanie się z szablonem projektu witryny sieci Web ASP.NET MVC 2 OpenID (C #) dostępnym w galerii VS. Po wyjęciu z pudełka jest wyposażony w uwierzytelnianie OpenID i obsługę dostawcy usług OAuth. Oznacza to, że Twoi użytkownicy mogą logować się za pomocą OpenID, a aplikacje i usługi innych firm mogą używać OAuth do wykonywania wywołań API w Twojej witrynie internetowej i uzyskiwania dostępu do danych użytkownika.

Wygląda na to, że chciałbyś dodać do tego szablonu projektu, gdy już zaczniesz, to możliwość logowania się użytkowników przy użyciu nazwy użytkownika i hasła, a także OpenID. Ponadto, jeśli chcesz, aby Facebook i Twitter były opcją dla Twoich użytkowników, musisz to również wdrożyć, ponieważ nie używają oni standardu OpenID. Jednak pobieranie DotNetOpenAuth zawiera przykłady do logowania za pomocą Twittera i Facebooka, więc masz tam pewne wskazówki.

Podejrzewam, że nie będziesz miał wiele do zrobienia w kwestii autoryzacji. Jest wyposażony w OAuth, jak powiedziałem wcześniej, i to prawdopodobnie Ci wystarczy.

Po pierwsze. Musisz mentalnie oddzielić to, co jest twoim API - od metod uwierzytelniania.

Twoje API to w zasadzie zasoby i metody manipulowania tymi zasobami. Możesz mieć kilka metod uwierzytelniania dostępu do swojego interfejsu API.

OAuth jest jednym z takich mechanizmów uwierzytelniania. Bycie dostawcą OAuth jest świetne, mimo że specyfikacja jest trochę trudna do zrozumienia, zwłaszcza części, które mają związek z podpisami. Po wdrożeniu protokołu OAuth aplikacje klienckie zwykle mają łatwy czas na uwierzytelnianie, ponieważ istnieje wiele bibliotek „open source, które są już gotowe, wystarczy zaimplementować” dostępne w większości języków.

O zaletach i wadach protokołu OAuth dyskutowano już od jakiegoś czasu. Aby jednak wyrobić sobie własną opinię, proponuję przeczytanie tego ostatecznego przewodnika, którego autorem jest Eran Hammer-Lahav , jedna z osób odpowiedzialnych za specyfikację OAuth.

Jedyną realną alternatywą dla OAuth, o ile to widzę, jest OAuth 2.0 i po prostu proste uwierzytelnianie podstawowe.

Poza tym mówisz o uwierzytelnianiu za pomocą Open-ID, tożsamości na Facebooku itp. To kolejne pytanie, które musisz sobie zadać. Ale to naprawdę wykracza poza zakres interfejsów API i OAuth. Dla mnie to bardziej kwestia tworzenia użytkowników w Twojej usłudze. Mogę się mylić.