Czym różni się OAuth 2 od OAuth 1?


604

Czy w prostych słowach ktoś może wyjaśnić różnicę między OAuth 2 i OAuth 1?

Czy OAuth 1 jest już przestarzały? Czy powinniśmy wdrażać OAuth 2? Nie widzę wielu implementacji OAuth 2; większość nadal używa OAuth 1, co budzi wątpliwości, że OAuth 2 jest gotowy do użycia. Czy to jest



Jeśli chcesz zobaczyć zwięzłe wyjaśnienie i szczegółowy przepływ (wraz ze schematami) OAuth, możesz sprawdzić oauthbible.com
Chris Ismael

Odpowiedź możesz znaleźć tutaj OAuth 2.0 - Omówienie
John Joe

Odpowiedzi:


529

Eran Hammer-Lahav wykonał świetną robotę, wyjaśniając większość różnic w swoim artykule Wprowadzenie do OAuth 2.0 . Podsumowując, oto kluczowe różnice:

Więcej przepływów OAuth, aby umożliwić lepszą obsługę aplikacji nieobsługujących przeglądarki. Jest to główna krytyka wobec OAuth ze strony aplikacji klienckich, które nie były oparte na przeglądarce. Na przykład w OAuth 1.0 aplikacje komputerowe lub aplikacje na telefony komórkowe musiały skierować użytkownika do otwarcia przeglądarki do żądanej usługi, uwierzytelnienia się w usłudze i skopiowania tokena z usługi z powrotem do aplikacji. Główną krytyką jest tutaj brak doświadczenia użytkownika. Dzięki OAuth 2.0 istnieją nowe sposoby uzyskiwania przez aplikację autoryzacji dla użytkownika.

OAuth 2.0 nie wymaga już aplikacji klienckich do szyfrowania. Powoduje to powrót do starego interfejsu API uwierzytelniania na Twitterze, który nie wymagał aplikacji do tokenów skrótu HMAC i ciągów żądań. Dzięki OAuth 2.0 aplikacja może składać żądania przy użyciu tylko wystawionego tokena za pośrednictwem protokołu HTTPS.

Podpisy OAuth 2.0 są znacznie mniej skomplikowane. Nigdy więcej specjalnego parsowania, sortowania lub kodowania.

Tokeny dostępu OAuth 2.0 są „krótkotrwałe”. Zazwyczaj tokeny dostępu OAuth 1.0 mogą być przechowywane przez rok lub dłużej (Twitter nigdy nie pozwala im wygasnąć). OAuth 2.0 ma pojęcie tokenów odświeżania. Chociaż nie jestem do końca pewien, co to jest, domyślam się, że twoje tokeny dostępu mogą być krótkotrwałe (tj. Oparte na sesji), podczas gdy twoje tokeny odświeżania mogą być „czasem życia”. Możesz użyć tokena odświeżania, aby uzyskać nowy token dostępu, zamiast konieczności ponownego autoryzowania aplikacji przez użytkownika.

Wreszcie, protokół OAuth 2.0 ma zapewniać czysty podział ról między serwerem odpowiedzialnym za obsługę żądań OAuth a serwerem obsługującym autoryzację użytkownika. Więcej informacji na ten temat znajduje się w wyżej wymienionym artykule.


2
Czy ktoś mógłby wyjaśnić, jak różnią się adresy zwrotne między oauth 1 i 2?
Brian Armstrong,

2
Protokół OAuth 2.0 będzie przestrzegał protokołu OAuth tylko wtedy, gdy zostanie zatwierdzony jako RFC. Obecnie jest to wersja internetowa, ale planuje się stać się standardem internetowym (o ile można to zaplanować). Zajmie to jednak lata, ponieważ duże części ram nie są jeszcze określone. Prawdopodobnie w najbliższych latach zostanie opublikowana cała rodzina Szkiców Internetowych, z których każdy dotyczy różnych aspektów ram autoryzacji OAuth 2.0. Aby zobaczyć, dlaczego tak jest, odwiedź tools.ietf.org/html/draft-ietf-oauth-v2 i wyszukaj „poza zakresem niniejszej specyfikacji”;)
Håvard Geithus

48
Autor artykułu napisał w zeszłym roku kontynuację pod tytułem „OAuth 2.0 i droga do piekła”, którą można przeczytać tutaj: web.archive.org/web/20120731155632/http : //hueniverse.com/2012/... Istotna różnica między nimi to bezpieczeństwo - o czym świadczy brak kryptografii w wersji 2.0.
kdazzle

4
Bezpieczeństwo OAuth 1.0 opiera się na założeniu, że tajny klucz osadzony w aplikacji klienckiej może być poufny, ale założenie jest naiwne. W OAuth 2.0 taka naiwna aplikacja kliencka nazywa się klientem poufnym . Nie ma praktycznej różnicy w poziomie bezpieczeństwa między klientami OAuth 1.0 a poufnymi klientami OAuth 2.0. „OAuth 2.0 i droga do piekła” nie rozumie tego.
Takahiko Kawasaki,

6
@kdazzle, ten link został przeniesiony tutaj: hueniverse.com/oauth-2-0- i
the

193

Widzę tu świetne odpowiedzi, ale brakuje mi kilku diagramów i odkąd musiałem pracować z Spring Framework, natrafiłem na ich wyjaśnienia .

Poniższe diagramy uważam za bardzo przydatne. Ilustrują różnicę w komunikacji między stronami z OAuth2 i OAuth1.


OAuth 2

wprowadź opis zdjęcia tutaj


OAuth 1

wprowadź opis zdjęcia tutaj


3
gdzie w tym przepływie używany jest „sekret_klienta”?
ashwintastic

3
Jeśli masz na myśli tajemnicę, którą wprowadza użytkownik po przekierowaniu do dostawcy (np. Facebook, Twitter, Google itp.), Będzie to krok 2 dla OAuth 2i krok 4 dla OAuth 1.
nyxz

Dlaczego na obu diagramach jest krok dostawcy usług o nazwie „Użytkownik udziela autoryzacji?” Wydaje się, że to wstecz lub źle. Czy to „użytkownik” nie szuka autoryzacji?
Forbin

@Forbin Ponieważ ten krok dzieje się po stronie usługodawcy. Jesteś na ich stronie, gdzie widzisz dotacje, których wymaga od ciebie usługa, i musisz wyrazić zgodę na udostępnienie tych informacji usłudze, w której próbujesz się uwierzytelnić. StackOverflow faktycznie ma opcję logowania za pomocą konta Google. Działa w ten sam sposób. SO poprosi Google o wyświetlenie Twojego adresu e-mail i musisz się na to zgodzić.
nyxz

91

Poprzednie wyjaśnienia są zbyt szczegółowe i skomplikowane IMO. Krótko mówiąc, OAuth 2 przekazuje zabezpieczenia do protokołu HTTPS. OAuth 1 nie wymagał tego i dlatego miał alternatywne metody radzenia sobie z różnymi atakami. Metody te wymagały od aplikacji włączenia się w pewne protokoły bezpieczeństwa, które są skomplikowane i mogą być trudne do wdrożenia. Dlatego łatwiej jest po prostu polegać na HTTPS w zakresie bezpieczeństwa, aby twórcy aplikacji nie musieli się tym martwić.

Jeśli chodzi o inne pytania, odpowiedź zależy. Niektóre usługi nie wymagają użycia HTTPS, zostały opracowane przed OAuth 2 lub mają inne wymagania, które mogą uniemożliwić korzystanie z OAuth 2. Co więcej, wiele dyskusji dotyczy samego protokołu OAuth 2. Jak widać, na Facebooku, Google i kilku innych zaimplementowano nieznacznie różne wersje protokołów. Dlatego niektórzy ludzie trzymają się OAuth 1, ponieważ jest on bardziej jednolity na różnych platformach. Niedawno protokół OAuth 2 został sfinalizowany, ale musimy jeszcze zobaczyć, jak przyjmie jego przyjęcie.


11
Więc w zasadzie OAuth2 działa z HTTPS i dlatego jest prostszy niż OAuth1, który musi być nieco bardziej złożony, ponieważ może działać bez HTTPS?
Micro

@MicroR Oto jedna praktyczna definicja! ;)
EralpB

36

Zauważ, że istnieją poważne argumenty bezpieczeństwa przeciwko korzystaniu z Oauth 2:

jeden ponury artykuł

i bardziej techniczny

Uwaga: pochodzą one od głównego autora Oauth 2.

Kluczowe punkty:

  • Oauth 2 nie zapewnia żadnych zabezpieczeń oprócz SSL, podczas gdy Oauth 1 jest niezależny od transportu.

  • w pewnym sensie SSL nie jest bezpieczny, ponieważ serwer nie weryfikuje połączenia, a wspólne biblioteki klienta ułatwiają ignorowanie awarii.

    Problem z SSL / TLS polega na tym, że gdy nie uda się zweryfikować certyfikatu po stronie klienta, połączenie nadal działa. Za każdym razem, gdy zignorowanie błędu prowadzi do sukcesu, programiści właśnie to zrobią. Serwer nie ma możliwości wymuszenia weryfikacji certyfikatu, a nawet gdyby mógł, atakujący na pewno nie.

  • możesz odciąć wszystkie swoje zabezpieczenia, co jest znacznie trudniejsze w OAuth 1.0:

    Drugim częstym potencjalnym problemem są literówki. Czy uważasz, że jest to właściwy projekt, jeśli pominięcie jednego znaku („s” w „https”) unieważnia całe bezpieczeństwo tokena? A może wysyłanie żądania (przez prawidłowe i zweryfikowane połączenie SSL / TLS) do niewłaściwego miejsca docelowego (powiedz „ http://gacebook.com ”?). Pamiętaj, że możliwość korzystania z tokenów nośnika OAuth z wiersza poleceń była wyraźnie promowana przez tokeny nośników przypadków użycia.


4
argument „literówka” nie jest zbyt ważny - powszechną praktyką jest przekierowywanie z http na https
Oleg Mikheev

2
@OlegMikheev Tak, ale potrzeba tylko jednego żądania http (no-s), aby MITM mógł obwąchać twoje nagłówki, a Twój token jest teraz używany przez kogoś innego!
Patrick James McDougle,

3
jeśli przez nagłówki masz na myśli pliki cookie, powinny one być bezpieczne . Poza tym nie widzę, jak literówka użytkownika (w adresie URL przeglądarki) może ujawniać tokeny, nie powinny nawet znajdować się w nagłówkach
Oleg Mikheev

2
Jako dodatkowy argument przeciwko argumentowi „literówka” dostawca usług może odrzucić wszelkie żądania OAuth 2.0, które nie są przesyłane za pośrednictwem protokołu https i odwołać token dostępu w tym żądaniu.
skeller88,

32

Bezpieczeństwo protokołu OAuth 1.0 ( RFC 5849 ) opiera się na założeniu, że tajny klucz osadzony w aplikacji klienckiej może być poufny. Jednak założenie jest naiwne.

W OAuth 2.0 ( RFC 6749 ) taka naiwna aplikacja kliencka nazywa się klientem poufnym . Z drugiej strony aplikacja kliencka w środowisku, w którym trudno jest zachować poufność tajnego klucza, nazywa się klientem publicznym . Zobacz 2.1. Typy klientów, aby uzyskać szczegółowe informacje.

W tym sensie OAuth 1.0 jest specyfikacją tylko dla poufnych klientów.

OAuth 2.0 i droga do piekła ” mówi, że OAuth 2.0 jest mniej bezpieczny, ale nie ma praktycznej różnicy w poziomie bezpieczeństwa między klientami OAuth 1.0 a poufnymi klientami OAuth 2.0. Protokół OAuth 1.0 wymaga obliczenia podpisu, ale nie zwiększa bezpieczeństwa, jeśli jest już zapewniony, że tajny klucz po stronie klienta może być poufny. Obliczanie podpisu jest po prostu uciążliwym obliczeniem bez praktycznego zwiększenia bezpieczeństwa. Mam na myśli, w porównaniu z prostotą, że klient OAuth 2.0 łączy się z serwerem przez TLS i po prostu przedstawia client_idi client_secretnie można powiedzieć, że uciążliwe obliczenia są lepsze pod względem bezpieczeństwa.

Ponadto RFC 5849 (OAuth 1.0) nie wspomina o otwartych przekierowaniach, podczas gdy RFC 6749 (OAuth 2.0). Oznacza to, że oauth_callbackparametr OAuth 1.0 może stać się luką bezpieczeństwa.

Dlatego nie sądzę, aby OAuth 1.0 był bezpieczniejszy niż OAuth 2.0.


[14 kwietnia 2016 r.] Dodatek w celu wyjaśnienia mojego punktu

Bezpieczeństwo OAuth 1.0 opiera się na obliczeniach sygnatur. Podpis jest obliczany przy użyciu tajnego klucza, gdzie tajny klucz jest kluczem współdzielonym dla HMAC-SHA1 ( RFC 5849, 3.4.2 ) lub kluczem prywatnym dla RSA-SHA1 ( RFC 5849, 3.4.3 ). Każdy, kto zna tajny klucz, może obliczyć podpis. Tak więc, jeśli tajny klucz zostanie naruszony, złożoność obliczeń podpisu jest bez znaczenia, jakkolwiek jest złożona.

Oznacza to, że bezpieczeństwo OAuth 1.0 nie opiera się na złożoności i logice obliczeń podpisu, lecz jedynie na poufności tajnego klucza. Innymi słowy, dla bezpieczeństwa OAuth 1.0 potrzebny jest tylko warunek, że tajny klucz może być poufny. Może się to wydawać ekstremalne, ale obliczenia sygnatur nie zwiększają bezpieczeństwa, jeśli warunek jest już spełniony.

Podobnie OAuth 2.0 poufne klienci polegają na tym samym stanie. Jeśli warunek jest spełniony już jest jakiś problem w tworzeniu bezpiecznego połączenia przy użyciu protokołu TLS oraz wysyłanie client_idi client_secretdo serwera autoryzacji za pośrednictwem bezpiecznego połączenia? Czy istnieje jakaś duża różnica w poziomie bezpieczeństwa między poufnymi klientami OAuth 1.0 i OAuth 2.0, jeśli oba polegają na tym samym stanie?

Nie mogę znaleźć żadnego dobrego powodu, by OAuth 1.0 obwiniał OAuth 2.0. Faktem jest, że (1) OAuth 1.0 jest tylko specyfikacją tylko dla klientów poufnych, a (2) OAuth 2.0 uprościł protokół dla klientów poufnych i obsługiwanych klientów publicznych . Niezależnie od tego, czy wiadomo, czy nie, aplikacje na smartfony są klasyfikowane jako klienci publiczni ( RFC 6749, 9 ), którzy korzystają z OAuth 2.0.


7
Wysyłanie tajemnic zamiast podpisów, czy to przez HTTP, HTTPS itp., Zawsze będzie wiązało się z domniemanym zagrożeniem bezpieczeństwa z powodu MITM na poziomie protokołu. Teraz są 2 sposoby na znalezienie tajemnic zamiast tylko 1: zrootuj urządzenie lub sfałszuj certyfikaty root (zdarzyło się to wcześniej, więc nie jest to zbyt daleko idące). Kiedy twoim modelem bezpieczeństwa jest „eh, pozwól transportowi się tym zająć”, to prawda, że ​​nie będzie MNIEJSZY bezpieczny niż protokół. Ale monolityczne modele bezpieczeństwa == jeden punkt wejścia dla wielu usług. Jest „wystarczająco dobry” dla pragmatycznych inżynierów, ale nigdy nie będzie „tak bezpieczny” jak alternatywny model zdecentralizowany.
Mark G.

23

Podpisy OAuth 2.0 nie są wymagane dla rzeczywistych wywołań API po wygenerowaniu tokena. Ma tylko jeden token bezpieczeństwa.

OAuth 1.0 wymaga od klienta wysłania dwóch tokenów bezpieczeństwa dla każdego wywołania API i użycia obu do wygenerowania podpisu. Wymaga to, aby punkty końcowe chronionych zasobów miały dostęp do poświadczeń klienta w celu zweryfikowania żądania.

Tutaj opisano różnicę między OAuth 1.0 i 2.0 oraz sposób działania obu.


22

OAuth 2 jest najwyraźniej stratą czasu (z ust osoby, która była w to mocno zaangażowana):

https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

Mówi (zredagowany dla zwięzłości i pogrubiony dla podkreślenia):

... Nie mogę już być powiązany ze standardem OAuth 2.0. Zrezygnowałem z roli głównego autora i redaktora, wycofałem swoje nazwisko ze specyfikacji i opuściłem grupę roboczą. Usunięcie mojego nazwiska z dokumentu, nad którym starannie pracowałem przez trzy lata, a ponad dwa tuziny szkiców nie było łatwe. Decyzja o kontynuowaniu wysiłku, który prowadziłem przez ponad pięć lat, była bolesna.

... Na koniec doszedłem do wniosku, że OAuth 2.0 to zły protokół. WS- * źle. Jest wystarczająco źle, że nie chcę już być z tym związany. ... W porównaniu z OAuth 1.0 specyfikacja 2.0 jest bardziej złożona, mniej interoperacyjna, mniej użyteczna, bardziej niekompletna, a co najważniejsze, mniej bezpieczna.

Żeby było jasne, OAuth 2.0 z ręki programisty z głębokim zrozumieniem bezpieczeństwa w sieci prawdopodobnie zapewni bezpieczną implementację. Jednak z uwagi na większość programistów - podobnie jak w ciągu ostatnich dwóch lat - 2.0 może przynieść niepewne wdrożenia.


7
Należy pamiętać, że odpowiedzi tylko do linków są odradzane, odniesienia z czasem stają się nieaktualne. Rozważ dodanie tutaj autonomicznego streszczenia, zachowując link jako odniesienie.
kleopatra

6
Bezpieczeństwo OAuth 1.0 opiera się na założeniu, że tajny klucz osadzony w aplikacji klienckiej może być poufny, ale założenie jest naiwne w przypadku aplikacji na smartfony. W OAuth 2.0 taka naiwna aplikacja kliencka nazywa się klientem poufnym . Nie ma praktycznej różnicy w poziomie bezpieczeństwa między klientami OAuth 1.0 a poufnymi klientami OAuth 2.0. „OAuth 2.0 i droga do piekła” nie rozumie tego.
Takahiko Kawasaki,

15

Jeśli potrzebujesz zaawansowanych wyjaśnień, przeczytaj obie specyfikacje:

https://oauth.net/core/1.0a/

https://oauth.net/2/

Jeśli potrzebujesz jasnego wyjaśnienia różnic w przepływach, może to pomóc:

Przepływ OAuth 1.0

  1. Aplikacja kliencka rejestruje się u dostawcy, takiego jak Twitter.
  2. Twitter zapewnia klientowi „tajemnicę konsumenta” unikalną dla tej aplikacji.
  3. Aplikacja kliencka podpisuje wszystkie żądania OAuth na Twitterze za pomocą unikalnego „tajemnicy klienta”.
  4. Jeśli którekolwiek z żądań OAuth jest zniekształcone, brakuje danych lub jest podpisane nieprawidłowo, żądanie zostanie odrzucone.

Przepływ OAuth 2.0

  1. Aplikacja kliencka rejestruje się u dostawcy, takiego jak Twitter.
  2. Twitter zapewnia klientowi „sekret klienta” unikalny dla tej aplikacji.
  3. Aplikacja kliencka zawiera „klucz tajny klienta” do każdego żądania zwykle jako nagłówek http.
  4. Jeśli którekolwiek z żądań OAuth jest zniekształcone, brakuje danych lub zawiera nieprawidłowy klucz tajny, żądanie zostanie odrzucone.

Źródło: https://codiscope.com/oauth-2-0-vs-oauth-1-0/


2
Czy widzisz znaki pogrubioną czcionką? Może funkcjonalny może mieć tę samą koncepcję, ale technicznie rzecz biorąc, użyj prostego nagłówka (oauth2), podpisanie całego żądania jest zupełnie inne . Zwróć uwagę i
popraw

1
przeczytaj swoją odpowiedź i spróbuj ją zrozumieć. „Podpisuje wszystkie żądania w tajemnicy” i „wysyłaj w tajemnicy wszystkie żądania”. Nikt przy zdrowych zmysłach nie zrozumie tutaj różnicy, chyba że już ich użył. Znam różnicę, ale OP nie. Ta odpowiedź jeszcze bardziej pomieszać OP, stąd też głosy negatywne. Takie niejasne odpowiedzi zasługują na głosowanie. Przeczytaj inne odpowiedzi tutaj, które są znacznie bardziej szczegółowe i zawierają wiele informacji.
saran3h

Ma go 12 programistów . oauth1 i oauth2 mają wiele różnic. Poprzednie odpowiedzi obejmują je i jak powiedziałem , możesz przeczytać ten oauth.net/core/1.0a lub ten oauth.net/2, aby uzyskać własną odpowiedź. Moim celem jest pokazanie jednej z najbardziej znanych różnic technicznych, gdy programista musi opracować klienta spoczynkowego.
JRichardsz

7

OAuth 2.0 obiecuje uprościć sprawy w następujący sposób:

  1. SSL jest wymagany do całej komunikacji wymaganej do wygenerowania tokena. Jest to ogromny spadek złożoności, ponieważ te złożone podpisy nie są już wymagane.
  2. Podpisy nie są wymagane dla rzeczywistych wywołań interfejsu API po wygenerowaniu tokena - zdecydowanie zaleca się także SSL.
  3. Po wygenerowaniu tokena OAuth 1.0 wymagał, aby klient wysyłał dwa tokeny bezpieczeństwa przy każdym wywołaniu API i używał obu do wygenerowania podpisu. OAuth 2.0 ma tylko jeden token bezpieczeństwa i nie jest wymagany podpis.
  4. Jasno określono, które części protokołu są implementowane przez „właściciela zasobów”, który jest rzeczywistym serwerem, który implementuje API, a które części mogą być implementowane przez osobny „serwer autoryzacji”. Ułatwi to produktom takim jak Apigee oferowanie obsługi OAuth 2.0 dla istniejących interfejsów API.

Źródło: http://blog.apigee.com/detail/oauth_differences


1

Z punktu widzenia bezpieczeństwa wybrałbym OAuth 1. Zobacz OAuth 2.0 i drogę do piekła

cytat z tego linku: „Jeśli obecnie z powodzeniem używasz 1.0, zignoruj ​​2.0. Nie oferuje on żadnej rzeczywistej wartości powyżej 1,0 (domyślam się, że programiści twoich klientów do tej pory wymyślili sygnatury 1.0).

Jeśli dopiero zaczynasz przygodę z tą przestrzenią i uważasz się za eksperta w dziedzinie bezpieczeństwa, skorzystaj z wersji 2.0 po dokładnym zbadaniu jej funkcji. Jeśli nie jesteś ekspertem, użyj wersji 1.0 lub skopiuj implementację 2.0 dostawcy, któremu ufasz, aby zrobić to dobrze (dokumenty API Facebooka są dobrym miejscem na rozpoczęcie). Wersja 2.0 jest lepsza na dużą skalę, ale jeśli przeprowadzasz poważną operację, prawdopodobnie masz na miejscu ekspertów ds. Bezpieczeństwa, którzy mogą to wszystko rozwiązać. ”

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.