OAuth 2.0: Korzyści i przypadki użycia - dlaczego?

Czy ktoś mógłby wyjaśnić, co jest dobrego w OAuth2 i dlaczego powinniśmy to wdrożyć? Pytam, bo jestem trochę zdezorientowany - oto moje obecne przemyślenia:

Żądania OAuth1 (a dokładniej HMAC) wydają się logiczne, łatwe do zrozumienia, łatwe do opracowania i naprawdę, naprawdę bezpieczne.

Zamiast tego OAuth2 wysyła żądania autoryzacji, tokeny dostępu i tokeny odświeżania, a na samym początku sesji musisz wysłać 3 żądania, aby uzyskać dane, których szukasz. I nawet wtedy jedno z twoich żądań ostatecznie zakończy się niepowodzeniem, gdy wygaśnie token.

Aby uzyskać kolejny token dostępu, użyj tokena odświeżania, który został przekazany w tym samym czasie, co token dostępu. Czy to sprawia, że ​​token dostępu jest daremny z punktu widzenia bezpieczeństwa?

Co więcej, jak ostatnio pokazał / r / netsec, SSL nie jest całkowicie bezpieczny, więc popychanie mnie do umieszczenia wszystkiego w TLS / SSL zamiast bezpiecznego HMAC dezorientuje mnie.

OAuth przekonuje, że nie chodzi tu o 100% bezpieczeństwa, ale o opublikowanie i ukończenie. To nie brzmi obiecująco z punktu widzenia dostawcy. Widzę, co projekt chce osiągnąć, gdy wspomina o 6 różnych przepływach, ale po prostu nie pasują do siebie w mojej głowie.

Myślę, że bardziej trudno jest mi zrozumieć, jakie są korzyści i rozumowanie, niż w rzeczywistości nie lubić go, więc może to być trochę nieuzasadniony atak, i przepraszam, jeśli to może wydawać się rantem.

Tło: Napisałem stosy klientów i serwerów dla OAuth 1.0a i 2.0.

Zarówno OAuth 1.0a, jak i 2.0 obsługują uwierzytelnianie dwunożne , w którym serwer ma pewność tożsamości użytkownika, oraz uwierzytelnianie trójnożne , w którym serwer zapewnia dostawca treści o tożsamości użytkownika. Uwierzytelnianie trójnożne to miejsce, w którym pojawiają się prośby o autoryzację i tokeny dostępu, i należy pamiętać, że OAuth 1 również je ma.

Złożony: uwierzytelnianie trójnożne

Głównym punktem specyfikacji OAuth jest zapewnienie dostawcy treści (np. Facebook, Twitter itp.) Zapewnienia serwerowi (np. Aplikacji internetowej, która chce rozmawiać z dostawcą treści w imieniu klienta), że klient ma pewną tożsamość . To, co oferuje trójnożne uwierzytelnianie, to możliwość, aby klient ani serwer nigdy nie musieli znać szczegółów tej tożsamości (np. Nazwa użytkownika i hasło).

Bez (?) Zagłębiania się w szczegóły OAuth:

1. Klient przesyła żądanie autoryzacji do serwera, które potwierdza, że ​​klient jest legalnym klientem jego usługi.
2. Serwer przekierowuje klienta do dostawcy treści, aby poprosić o dostęp do jego zasobów.
3. Dostawca treści sprawdza tożsamość użytkownika i często prosi o pozwolenie na dostęp do zasobów.
4. Dostawca treści przekierowuje klienta z powrotem na serwer, powiadamiając go o sukcesie lub niepowodzeniu. To żądanie zawiera kod autoryzacyjny w przypadku powodzenia.
5. Serwer wysyła żądanie pozapasmowe do dostawcy treści i wymienia kod autoryzacyjny na token dostępu.

Serwer może teraz wysyłać żądania do dostawcy treści w imieniu użytkownika, przekazując token dostępu.

Każda wymiana (klient-> serwer, serwer-> dostawca treści) obejmuje sprawdzanie poprawności wspólnego klucza tajnego, ale ponieważ OAuth 1 może działać przez niezaszyfrowane połączenie, każda walidacja nie może przekazać klucza tajnego.

Dokonano tego, jak zauważyłeś, z HMAC. Klient używa tajnego klucza udostępnianego serwerowi do podpisywania argumentów żądania autoryzacji. Serwer pobiera argumenty, sam je podpisuje kluczem klienta i może sprawdzić, czy jest to legalny klient (w kroku 1 powyżej).

Podpis ten wymaga, aby zarówno klient, jak i serwer uzgodnili kolejność argumentów (więc podpisują dokładnie ten sam ciąg), a jednym z głównych zarzutów dotyczących OAuth 1 jest to, że zarówno serwer, jak i klienci muszą sortować i podpisać identycznie. To jest dziwaczny kod i albo jest poprawny, albo dostajesz 401 Unauthorizedz niewielką pomocą. Zwiększa to barierę pisania klienta.

Wymagając, aby żądanie autoryzacji działało przez SSL, OAuth 2.0 eliminuje potrzebę sortowania i podpisywania argumentów. Klient przekazuje swój sekret do serwera, który weryfikuje go bezpośrednio.

Te same wymagania obowiązują w połączeniu serwer-> dostawca treści, a ponieważ jest to protokół SSL, który usuwa jedną barierę w pisaniu serwera, który uzyskuje dostęp do usług OAuth.

To sprawia, że ​​jest dużo łatwiej w krokach 1, 2 i 5 powyżej.

W tym momencie nasz serwer ma token stałego dostępu, który jest nazwą użytkownika / hasłem równoważnym dla użytkownika. Może wysyłać żądania do dostawcy treści w imieniu użytkownika, przekazując token dostępu jako część żądania (jako argument zapytania, nagłówek HTTP lub dane formularza POST).

Jeśli dostęp do usługi treści jest uzyskiwany tylko za pośrednictwem protokołu SSL, to koniec. Jeśli jest dostępny przez zwykły HTTP, chcielibyśmy w jakiś sposób chronić ten token stałego dostępu. Każdy, kto wącha połączenie, może uzyskać dostęp do treści użytkownika na zawsze.

Rozwiązaniem w OAuth 2 jest token odświeżania . Token odświeżania staje się stałym ekwiwalentem hasła i jest zawsze przesyłany tylko przez SSL . Gdy serwer potrzebuje dostępu do usługi treści, wymienia token odświeżania na token dostępu krótkotrwały. W ten sposób wszystkie wąchalne dostępy HTTP są wykonywane za pomocą tokena, który wygaśnie. Google stosuje 5-minutowy okres ważności swoich interfejsów API OAuth 2.

Oprócz tokenów odświeżania OAuth 2 upraszcza całą komunikację między klientem, serwerem i dostawcą treści. A tokeny odświeżania istnieją tylko w celu zapewnienia bezpieczeństwa, gdy dostęp do zawartości jest niezaszyfrowany.

Uwierzytelnianie dwunożne

Czasami jednak serwer musi po prostu kontrolować dostęp do własnych treści. Uwierzytelnianie dwunożne umożliwia klientowi uwierzytelnienie użytkownika bezpośrednio na serwerze.

OAuth 2 standaryzuje niektóre rozszerzenia OAuth 1, które były szeroko stosowane. Ten, który znam najlepiej, został wprowadzony przez Twittera jako xAuth . Możesz to zobaczyć w OAuth 2 jako poświadczenia hasła właściciela zasobu .

Zasadniczo, jeśli możesz zaufać klientowi za pomocą poświadczeń użytkownika (nazwa użytkownika i hasło), może on wymienić je bezpośrednio z dostawcą treści na token dostępu. Dzięki temu OAuth jest znacznie bardziej przydatny w aplikacjach mobilnych - w przypadku uwierzytelniania trójnożnego musisz osadzić widok HTTP, aby obsłużyć proces autoryzacji z serwerem treści.

W przypadku OAuth 1 nie było to częścią oficjalnego standardu i wymagało takiej samej procedury podpisywania, jak w przypadku wszystkich innych żądań.

Właśnie wdrożyłem stronę OAuth 2 po stronie serwera za pomocą poświadczeń hasła właściciela zasobu, a z perspektywy klienta uzyskanie tokena dostępu stało się proste: zażądanie tokena dostępu z serwera, przekazanie identyfikatora / hasła klienta jako nagłówka autoryzacji HTTP i login / hasło użytkownika jako dane formularza.

Zaleta: prostota

Z punktu widzenia implementatora główne zalety, które widzę w OAuth 2, to zmniejszona złożoność. Nie wymaga procedury podpisywania żądań, co nie jest do końca trudne, ale z pewnością jest kłopotliwe. To znacznie zmniejsza nakład pracy niezbędny do działania jako klient usługi, czyli tam, gdzie (we współczesnym mobilnym świecie) najbardziej chcesz zminimalizować ból. Zmniejszona złożoność po stronie serwer-> dostawca treści czyni go bardziej skalowalnym w centrum danych.

I kodyfikuje w standardzie niektóre rozszerzenia OAuth 1.0a (takie jak xAuth), które są obecnie w powszechnym użyciu.

Po pierwsze, jak wyraźnie wskazano w uwierzytelnianiu OAuth

OAuth 2.0 nie jest protokołem uwierzytelniającym.

Uwierzytelnianie w kontekście użytkownika uzyskującego dostęp do aplikacji informuje aplikację, kim jest bieżący użytkownik i czy jest obecny. Pełny protokół uwierzytelnienia prawdopodobnie powie Ci także wiele atrybutów o tym użytkowniku, takich jak unikalny identyfikator, adres e-mail i jak zadzwonić, gdy aplikacja powie „Dzień dobry”.

Jednak OAuth nic nie mówi aplikacji. OAuth nie mówi absolutnie nic o użytkowniku, ani nie mówi, w jaki sposób użytkownik udowodnił swoją obecność, a nawet jeśli nadal tam jest. Jeśli chodzi o klienta OAuth, poprosił o token, otrzymał token i ostatecznie wykorzystał ten token do uzyskania dostępu do interfejsu API. Nie wie nic o tym, kto autoryzował aplikację lub czy w ogóle tam był użytkownik.

Istnieje standard uwierzytelniania użytkownika za pomocą OAuth: OpenID Connect, zgodny z OAuth2.

Token OpenID Connect ID to podpisany token internetowy JSON (JWT), który jest podawany aplikacji klienckiej obok zwykłego tokenu dostępu OAuth. Token identyfikatora zawiera zestaw oświadczeń dotyczących sesji uwierzytelniania, w tym identyfikator użytkownika (podrzędnego), identyfikator dostawcy tożsamości, który wydał token (iss), oraz identyfikator klienta, dla którego ten token został utworzony ( aud).

W Go możesz zobaczyć coreos / dex, OpenID Connect Identity (OIDC) i OAuth 2.0 Provider with Pluggable Connector.

Odpowiedź z tego postu vonc

Odpowiem na to pytanie nieco inaczej i będę bardzo precyzyjny i zwięzły, głównie dlatego, że @Peter T odpowiedział na wszystko.

Główną korzyścią wynikającą z tego standardu jest przestrzeganie dwóch zasad:

1. Rozdzielenie obaw.
2. Oddzielenie uwierzytelnienia od aplikacji internetowej, która zwykle służy do prowadzenia działalności gospodarczej.

W ten sposób,

1. Możesz wdrożyć alternatywę dla Single SignOn: jeśli masz wiele aplikacji, które ufają jednej STS. Mam na myśli jedną nazwę użytkownika dla wszystkich aplikacji.
2. Możesz włączyć swoją aplikację internetową (klient), aby uzyskać dostęp do zasobów, które należą do użytkownika i nie należą do aplikacji internetowej (klient).
3. Możesz zlecić proces uwierzytelnienia zaufanej stronie trzeciej i nigdy nie martw się o weryfikację autentyczności użytkownika.