Budujemy API REST za pomocą ASP.NET MVC. Ten interfejs API jest zasadniczo podobny i korzysta z API Factual v3. Używają 2-legged Oauth 1 dla swojego API. Nasz projekt jest bardzo podobny w tych aplikacjach, głównie mobilni będą używać naszego API za kulisami, aby świadczyć usługę. Użytkownik końcowy aplikacji nie będzie wiedział o naszym interfejsie API i dlatego nie będzie mieć żadnych poświadczeń. Zatem przekierowanie użytkownika przez okno przeglądarki do formularza autoryzacji (takiego jak Facebook) nie ma żadnego sensu. Moje pytania są następujące:Co jest najlepsze dla auth ASP.NET MVC REST API? OAuth 2.0 lub OAuth 1.0?
- Dlaczego przepływ OAuth2 jest najlepszy w tym scenariuszu?
- Czy powinniśmy używać Oauth2, czy tylko trzymać się 2-legged OAuth 1?
Dla odniesienia używamy C#/.NET, ASP.NET MVC 3 i planujemy użycie DotNetOpenAuth v4.
http://developer.factual.com/display/docs/Factual+Developer+APIs+Version+3
Ponieważ Oauth2 jest nowy, puszczamy z Oauth1. Pobrałem najnowszą wersję DotNetOpenAuth 4 (rc1). Im czas dotyku sortowania wszystkich przykładów, aby znaleźć taki, który jest podobny do tego, czego potrzebujemy. Używamy ASP.NET MVC 4 Web Api do budowania reszty api. Po prostu potrzebuję możliwości podpisania żądania za pomocą oauth z kluczem API i tajnym kluczem, następnie po stronie serwera ma atrybut autoryzacji, który dekoduje to żądanie i zatwierdza go względem klucza i tajnego klucza w bazie danych. Który przykład powinienem śledzić? – craigtadlock
Przykłady OAuthServiceProvider i OAuthConsumer są najbardziej odpowiednie. Wygląda jednak na to, że użytkownicy nie mają związku z twoim scenariuszem - więc brzmi to tak, jakbyś opisywał [0-legged OAuth] (http://blog.nerdbank.net/2011/06/what-is-2-legged-oauth .html). Chociaż nie sądzę, że istnieje do tego konkretna próbka, powinno być dość proste przeniesienie powyższych próbek, aby pasowało do twoich potrzeb. –