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

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

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.

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

OAuth 1

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.

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.

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.

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.

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.

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.

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/

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

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ć. ”