W jaki sposób OAuth 2 chroni przed takimi atakami, jak powtórka przy użyciu tokena zabezpieczającego?


564

Jak rozumiem, następujący łańcuch zdarzeń występuje w OAuth 2 w celu uzyskania Site-Adostępu do informacji użytkownikaSite-B .

  1. Site-Arejestruje się Site-Bi uzyskuje Sekret i identyfikator.
  2. Gdy Użytkownik mówi Site-Ado dostępu Site-B, Użytkownik zostaje wysłany do Site-Bktórych powiedzieć Site-B, że rzeczywiście jak dać Site-Auprawnienia do określonej informacji.
  3. Site-Bprzekierowuje użytkownika z powrotem Site-A, wraz z kodem autoryzacyjnym.
  4. Site-Anastępnie przekazuje ten kod autoryzacyjny wraz z jego sekretem Site-Bw zamian za token zabezpieczający.
  5. Site-Anastępnie wysyła żądania Site-Bw imieniu użytkownika , łącząc token zabezpieczający z żądaniami.

Jak to wszystko działa pod względem bezpieczeństwa i szyfrowania na wysokim poziomie? W jaki sposób OAuth 2 chroni przed takimi atakami, jak powtórka przy użyciu tokena zabezpieczającego?


49
oauth2 po prostu wyjaśniono tutaj: gist.github.com/mziwisky/10079157
Paolo

4
Przeczytaj specyfikację: tools.ietf.org/html/rfc6749 Możesz być zaskoczony, jak to jest zrozumiałe. Jest to również poprawne, co może nie być takie złe.
Kris Vandermotten

1
To pytanie i jego (aktualne) odpowiedzi skupiają się na jednym konkretnym „typie grantu” w OAuth 2.0 (tj. code), Ale istnieją inne typy grantu zdefiniowane w OAuth 2.0, które są odpowiednie dla różnych przypadków użycia (np. Niezwiązanych z użytkownikiem).
Hans Z.

4
Och, dlaczego nie zastąpić „Witryny B” czymś bardziej czytelnym, jak „Witryna IdProvider”?
Yurii,

Odpowiedzi:


1378

Jak działa OAuth 2.0 w prawdziwym życiu:

Jadąc do pracy, jechałem do piekarni Olafa, kiedy zobaczyłem w oknie najsmaczniejszy pączek - chodziło mi o czekoladową dobroć. Więc wszedłem do środka i zażądałem „muszę mieć tego pączka!”. Powiedział „na pewno będzie to 30 $”.

Tak, wiem, 30 $ za jednego pączka! To musi być pyszne! Sięgnąłem po portfel, gdy nagle usłyszałem, jak szef kuchni krzyczy: „NIE! Nie ma dla ciebie pączka”. Zapytałem: dlaczego? Powiedział, że akceptuje tylko przelewy bankowe.

Poważnie? Tak, mówił poważnie. Prawie odeszłam tam, ale wtedy pączek zawołał do mnie: „Zjedz mnie, jestem pyszna ...”. Kim jestem, aby nie stosować się do poleceń pączka? Powiedziałem ok.

Wręczył mi notatkę z jego imieniem (szef kuchni, a nie pączek): „Powiedz im, że przysłał ci Olaf”. Jego imię było już na notatce, więc nie wiem, o co chodziło, ale dobrze.

Pojechałem półtorej godziny do mojego banku. Wręczyłem banknot bankomatowi; Powiedziałem jej, że Olaf mnie przysłał. Posłała mi jeden z tych spojrzeń: „Mogę czytać”.

Wzięła moją notatkę, poprosiła o mój dokument tożsamości, zapytała, ile pieniędzy można mu dać. Powiedziałem jej 30 dolarów. Zrobiła bazgroły i podała mi kolejną notatkę. Ten miał kilka liczb, tak sądzę, że tak śledzą notatki.

W tym momencie umieram z głodu. Wybiegłem stamtąd półtorej godziny później wróciłem, stojąc przed Olafem z wyciągniętą notatką. Wziął go, obejrzał i powiedział: „Wrócę”.

Myślałem, że dostał mój pączek, ale po 30 minutach zacząłem się podejrzewać. Zapytałem więc faceta za ladą „Where's Olaf?”. Powiedział „Poszedł po pieniądze”. "Co masz na myśli?". „Robi notatki do banku”.

Huh ... więc Olaf wziął notatkę, którą dał mi bank, i wrócił do banku, żeby pobrać pieniądze z mojego konta. Ponieważ miał banknot, który dał mi bank, bank wiedział, że jest facetem, o którym mówię, a ponieważ rozmawiałem z bankiem, wiedzieli, że może dać mu tylko 30 USD.

Musiało mi to zająć dużo czasu, aby to zrozumieć, ponieważ zanim spojrzałem w górę, Olaf stał przede mną i w końcu podał mi pączka. Zanim odszedłem, musiałem zapytać: „Olaf, czy zawsze sprzedawałeś w ten sposób pączki?”. „Nie, robiłem to inaczej”.

Huh Gdy wracałem do samochodu, zadzwonił mój telefon. Nie zawracałem sobie głowy odpowiedzią, prawdopodobnie to moja praca wymagała zwolnienia mnie, mój szef jest taki cholerny. Poza tym przyłapałem się na myśleniu o procesie, przez który właśnie przeszedłem.

Myślę o tym: mogłem pozwolić Olafowi pobrać 30 USD z mojego konta bankowego bez konieczności podawania mu informacji o moim koncie. I nie musiałem się martwić, że wyjmie za dużo pieniędzy, ponieważ już powiedziałem bankowi, że wolno mu wziąć tylko 30 $. A bank wiedział, że był odpowiednim facetem, ponieważ miał notatkę, którą mi dali, aby dać Olafowi.

Ok, pewnie wolałbym dać mu 30 dolarów z kieszeni. Ale teraz, gdy miał już tę notatkę, mogłem po prostu powiedzieć bankowi, żeby pozwolił mu wziąć 30 dolarów co tydzień, a potem mogłem tylko pojawić się w piekarni i nie musiałem już iść do banku. Gdybym chciał, mógłbym nawet zamówić pączek telefonicznie.

Oczywiście, że nigdy tego nie zrobię - ten pączek był obrzydliwy.

Zastanawiam się, czy to podejście ma szersze zastosowania. Wspomniał, że to jego drugie podejście, które mogę nazwać Olaf 2.0. W każdym razie lepiej wracam do domu, muszę zacząć szukać nowej pracy. Ale zanim dostanę jeden z tych koktajli truskawkowych z tego nowego miejsca w mieście, potrzebuję czegoś, co zmyje smak tego pączka.


41
Cóż, w praktyce Olaf powinien móc pobierać z twojego konta 30 USD w dowolnym momencie, nawet jeśli nie zamówisz pączka. Co ciekawe, to jest główny cel w prawdziwych scenariuszach oauth2.0 :) To z pewnością świetna odpowiedź, ale ktokolwiek to czyta, przejdź do sedna, o którym Paolo wspomniał w swoim komentarzu do pytania ( gist.github.com/mziwisky/ 10079157 ). Dobra uzupełniająca lektura, dzięki której koncepcja jest krystalicznie czysta.
Samiron,

4
Świetna odpowiedź, ale 2 punkty do podniesienia: 1. Jak zauważył @Samiron, Olaf byłby w stanie wziąć 30 $ w dowolnym momencie. 2. W prawdziwym scenariuszu OAuth2.0 Olaf nie będzie w stanie obsłużyć pączka przed wyjęciem pieniędzy z banku. W tym przykładzie mógł zatrzymać czek i po prostu wręczyć Luisowi jego zasłużony pączek. Jeśli więc zmienimy przykład, aby zezwolić Olafowi na otrzymywanie ciasta od jakiejś strony trzeciej, którą znam, to miałoby to większy sens, ponieważ Olaf musiałby dostać ciasto, zanim zacznie wypiekać pączek (zakładając, że Olaf jest samotnym pączkiem) był wyłącznie w celu wyświetlania!).
Ticker23

4
ticker23, historia pączka niestety przewyższa twoją techniczną korektę - sprzedałem tę historię, gdy ją przeczytałem. Został napisany przez Homera Simpsona.
shevy

4
@Prageeth Olaf zawsze przenosi banknot do iz banku w bezpiecznym pudełku, w którym wycieka atrament, jeśli zostanie zmieniony, przywrócenie banknotu zajęłoby wiele żywotów. Bank pobiera również odciski palców klientów przy pierwszej wizycie, jeśli Olaf zgubi palce w wypadku przy pieczeniu, będzie musiał poprosić Luisa o ponowne ustawienie przelewu bankowego, a bank będzie musiał zidentyfikować Olafa za pomocą tatuażu Łamanie chleba .
Chris

11
Uwielbiam słodkie odpowiedzi tak samo jak kolejna osoba, a kiedy ich słodycz pomaga uczynić odpowiedź bardziej dostępną, jest to niesamowite ... ale pod koniec dnia Stack Overflow polega na edukacji ludzi, a ta urocza historia tego nie robi. Aby nawet zrozumieć analogię pączka, musisz już zrozumieć, jak działa OAuth2, ale sedno odpowiedzi miało wyjaśnić dokładnie to. Proszę rozważyć edycję tej (górnej) odpowiedzi, aby faktycznie wyjaśnić pojęcia, a nie tylko odwoływać się do nich ukośnie na końcu ... nawet jeśli kosztuje to jeden lub dwa dowcipy.
machineghost

133

Na podstawie tego, co przeczytałem, tak to działa:

Ogólny przepływ opisany w pytaniu jest prawidłowy. W kroku 2 użytkownik X jest uwierzytelniany, a także autoryzuje dostęp witryny A do informacji użytkownika X w witrynie B. W kroku 4 witryna przekazuje swój sekret z powrotem do witryny B, uwierzytelniając się, a także kod autoryzacji, wskazując, co prosi o (token dostępu użytkownika X).

Ogólnie rzecz biorąc, OAuth 2 jest bardzo prostym modelem bezpieczeństwa, a szyfrowanie nigdy nie wchodzi bezpośrednio w grę. Zamiast tego zarówno Tajny, jak i Token Bezpieczeństwa są w zasadzie hasłami, a całość jest zabezpieczona tylko przez bezpieczeństwo połączenia https.

OAuth 2 nie ma ochrony przed atakami polegającymi na powtórzeniu tokena zabezpieczającego lub tajemnicy. Zamiast tego polega całkowicie na tym, że Witryna B jest odpowiedzialna za te elementy i nie pozwala im się wydostać, a także że są one wysyłane przez https podczas transportu (https chroni parametry adresu URL).

Celem kroku Kod autoryzacyjny jest po prostu wygoda, a sam kod autoryzacyjny nie jest szczególnie wrażliwy. Zapewnia wspólny identyfikator tokena dostępu użytkownika X dla witryny A, gdy użytkownik pyta witrynę B o token dostępu użytkownika X. Sam identyfikator użytkownika X na stronie B nie zadziałałby, ponieważ może być wiele zaległych tokenów dostępu czekających na przekazanie do różnych witryn w tym samym czasie.


28
Przeoczyłeś ważną funkcję kodu autoryzacyjnego. Dlaczego po prostu nie od razu zwrócisz token odświeżania (tak zwany tokenem bezpieczeństwa), zamiast dodatkowego kroku wymiany kodu autoryzacji? Ponieważ przechwycenie tokenu odświeżania pozwoli na ataki z powtórką, natomiast kodu autoryzacyjnego można użyć tylko raz.
Maurice Naftalin,

3
OK, @mauricen, to ma sens ... Ale czy atak powtórkowy nie mógł się równie dobrze przeprowadzić przy użyciu tokena odświeżania, ponieważ to właśnie kończy się przy każdym żądaniu?
Pan Mikkél,

15
Kod autoryzacyjny jest przekazywany przez użytkownika, więc (na przykład) może być przechowywany jako plik cookie (patrz stackoverflow.com/questions/4065657/… ). Token odświeżania przechodzi bezpośrednio między dwiema witrynami, więc jest znacznie mniej podatny na zagrożenia.
Maurice Naftalin,

Z ciekawości, czy OAuth zwraca jakieś unikalne identyfikatory do użycia przez program? Na przykład obecnie polegam na adresie MAC do identyfikacji użytkownika, ale powiedziawszy to, adresy MAC są niewiarygodne / łatwo podszywane się itp. Mogę po prostu zeskrobać mechanizm identyfikacji adresu MAC i przejść do OAuth, jeśli pozwala mi to na jednoznaczną identyfikację użytkowników.
theGreenCabbage

1
Zauważ na tym diagramie: tools.ietf.org/html/rfc6749#section-4.1, że „Tajny” nie jest pokazywany, tylko Identyfikator klienta (identyfikator w pytaniu). Dlaczego Sekret jest ważny i dlaczego nie jest uwzględniony w RFC? W pytaniu pojawia się również stan lokalny, który jest zalecany do przekazania w początkowej transmisji identyfikatora klienta (A), i przekierowanie z powrotem do klienta wraz z kodem autoryzacyjnym w celu ochrony przed XSSF.
David Williams

104

OAuth to protokół, za pomocą którego aplikacja innej firmy może uzyskiwać dostęp do danych przechowywanych w innej witrynie bez konta i hasła. Aby uzyskać bardziej oficjalną definicję, zobacz Wiki lub specyfikację.

Oto przykładowe zastosowanie:

  1. Loguję się na LinkedIn i chcę połączyć znajomych, którzy są w moich kontaktach Gmaila. LinkedIn obsługuje to. Będzie żądał bezpiecznego zasobu (mojej listy kontaktów Gmaila) od Gmaila. Więc klikam ten przycisk:
    Dodaj połączenie

  2. Pojawi się strona internetowa, która pokazuje stronę logowania Gmaila, kiedy wprowadzę swoje konto i hasło:
    Dodaj połączenie

  3. Następnie Gmail wyświetla stronę zgody, na której klikam „Akceptuję”: Dodaj połączenie

  4. Teraz LinkedIn może uzyskać dostęp do moich kontaktów w Gmailu: Dodaj połączenie

Poniżej przedstawiono schemat blokowy powyższego przykładu:

Dodaj połączenie

Krok 1: LinkedIn prosi o token z serwera autoryzacji Gmaila.

Krok 2: Serwer autoryzacji Gmail uwierzytelnia właściciela zasobu i wyświetla użytkownikowi stronę zgody. (użytkownik musi zalogować się do Gmaila, jeśli nie jest jeszcze zalogowany)

Krok 3: Użytkownik wyraża zgodę na LinkedIn, aby uzyskać dostęp do danych Gmaila.

Krok 4: serwer autoryzacji Gmaila odpowiada tokenem dostępu.

Krok 5: LinkedIn wywołuje interfejs API Gmaila za pomocą tego tokena dostępu.

Krok 6: Serwer zasobów Gmail zwraca twoje kontakty, jeśli token dostępu jest prawidłowy. (Token zostanie zweryfikowany przez serwer zasobów Gmaila)

Więcej informacji na temat protokołu OAuth można znaleźć tutaj .


Wszystkie twoje zdjęcia zaginęły. Jest jakaś szansa, że ​​możesz je załadować do stack.imgur?
ChrisF

1
Jak to może być poprawne? Czy ten proces nie jest inicjowany przez użytkownika siedzącego przed przeglądarką, a nie LinkedIn. Ale masz to jako krok 3. Tego nie rozumiem.
Matt

17
Najłatwiejsze wyjaśnienie. Dzięki, nigdy więcej nie kupię pączków
OverCoder

Czwarty krok linkedin powraca z tokenem autoryzacyjnym. Należy to podać w 5 kroku, w którym otrzymamy token dostępu i token odświeżania, który może być dalej wykorzystywany do chronionych zasobów.
amesh

@amesh Dzięki, masz rację, to jest przepływ kodu autoryzacji, tutaj właśnie podałem w uproszczony sposób, aby pokazać podstawową ideę OAuth 2.
Owen Cao

24

Rysunek 1, podniesiony z RFC6750 :

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

13

Tak działa Oauth 2.0, dobrze wyjaśnione w tym artykule

wprowadź opis zdjęcia tutaj


Czy możesz opisać OAUTH2 w kategoriach nieużywania Facebooka lub innej firmy, ale jeśli używasz tajnego klucza i tokenów TOTP w aplikacji telefonicznej do zabezpieczenia aplikacji internetowej?
Al Grant

Facebook jest serwerem autoryzacji w tym przykładzie, który wydaje token dostępu każdemu klientowi, aby mógł uzyskać dostęp do interfejsów API Facebooka. Jeśli chcesz zabezpieczyć interfejsy API, musisz wdrożyć własny serwer autoryzacji. Następnie decydujesz, jakiego typu Grantu chcesz użyć, aby uzyskać token dostępu. powiedz mi czego dokładnie chcesz wyjaśni.
Suraj

Patrzę na konfigurację z zabezpieczeniami Springboot. Klient (telefon) i aplikacja tajna wymieniają się przy rejestracji - następnie użyj uwierzytelnienia Google, aby wygenerować kod oparty na czasie / tajności, aby wprowadzić podczas logowania oprócz hasła.
Al Grant

czy mój ostatni komentarz już cię oświeca? Zobacz mój profil, aby uzyskać informacje na Twitterze
Al Grant,

przy rejestracji możesz uzyskać identyfikator klienta i sekret. Następnie telefon prześlij żądanie logowania przy użyciu identyfikatora klienta do aplikacji internetowej (serwer autoryzacji). aplikacja internetowa zweryfikuje identyfikator klienta i wyśle ​​OTP na telefon. Telefon wysyła kolejne żądanie z tajnym klientem do aplikacji internetowej w celu wymiany OTP za pomocą tokena dostępu. telefon używa tego tokenu accss, aby uzyskać dostęp do chronionych zasobów w aplikacji internetowej. Myślę, że byłby to przepływ Oauth2 dla danego scenariusza. daj mi znać, jeśli ci to pomoże.
Suraj,

10

To jest klejnot:

https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

Bardzo krótkie podsumowanie:

OAuth definiuje cztery role:

  1. Właściciel zasobów
  2. Klient
  3. Serwer zasobów
  4. Serwer autoryzacji

Ty (właściciel zasobów) masz telefon komórkowy. Masz kilka różnych kont e-mail, ale chcesz mieć wszystkie swoje konta e-mail w jednej aplikacji, więc nie musisz ciągle się przełączać. Tak więc Twój Gmail (Klient) prosi o dostęp (za pośrednictwem Serwera autoryzacji Yahoo) do wiadomości e-mail Yahoo (Serwer zasobów), abyś mógł czytać oba e-maile w aplikacji GMail.

Powodem istnienia OAuth jest to, że GMail nie przechowuje twojej nazwy użytkownika i hasła Yahoo.

wprowadź opis zdjęcia tutaj


8

Druga odpowiedź jest bardzo szczegółowa i dotyczy większości pytań postawionych przez PO.

Aby opracować, a konkretnie odpowiedzieć na pytanie PO: „W jaki sposób OAuth 2 chroni przed takimi atakami, jak powtórka przy użyciu tokena zabezpieczającego?”, Istnieją dwa dodatkowe zabezpieczenia w oficjalnych zaleceniach dotyczących wdrażania OAuth 2 :

1) Tokeny zazwyczaj mają krótki okres ważności ( http://tools.ietf.org/html/rfc6819#section-5.1.5.3 ):

Krótki czas ważności tokenów stanowi środek ochrony przed następującymi zagrożeniami:

  • powtórna rozgrywka...

2) Gdy token jest używany przez witrynę A, zaleca się, aby był on prezentowany nie jako parametry adresu URL, ale w polu nagłówka żądania autoryzacji ( http://tools.ietf.org/html/rfc6750 ):

Klienci POWINIEN wysyłać uwierzytelnione żądania za pomocą tokena nośnika, używając pola nagłówka „Autoryzacja” zgodnie ze schematem autoryzacji HTTP „Nośnik”. ...

NIE NALEŻY stosować metody „application / x-www-form-urlencoded”, z wyjątkiem kontekstów aplikacji, w których przeglądarki uczestniczące nie mają dostępu do pola nagłówka żądania „Autoryzacja”. ...

Parametr zapytania URI ... jest dołączony w celu udokumentowania bieżącego użycia; jego użycie nie jest zalecane z powodu braków bezpieczeństwa


3

Oto chyba najprostsze wyjaśnienie działania OAuth2 dla wszystkich 4 rodzajów przydziałów, tj. 4 różnych przepływów, w których aplikacja może uzyskać token dostępu.

Podobieństwo

Wszystkie przepływy typu dotacji składają się z 2 części:

  • Uzyskaj token dostępu
  • Użyj tokena dostępu

Druga część „token dostępu do użytkowania” jest taka sama dla wszystkich przepływów

Różnica

Pierwsza część przepływu „token dostępu” dla każdego typu dotacji jest różna.

Zasadniczo część „token dostępu” można podsumować jako składającą się z 5 kroków:

  1. Zarejestruj aplikację (klienta) wstępnie u dostawcy OAuth, np. Twittera itp., Aby uzyskać identyfikator klienta / klucz tajny
  2. Utwórz przycisk logowania społecznościowego z identyfikatorem klienta i wymaganymi zakresami / uprawnieniami na swojej stronie, aby po kliknięciu użytkownik został przekierowany do dostawcy OAuth w celu uwierzytelnienia
  3. Dostawca OAuth prosi użytkownika o udzielenie zgody na Twoją aplikację (klienta)
  4. Dostawca OAuth wydaje kod
  5. Aplikacja (klient) nabywa token dostępu

Poniżej znajduje się schemat porównujący, w jaki sposób przepływ każdego rodzaju przydziału jest inny na podstawie 5 kroków.

Ten schemat pochodzi z https://blog.oauth.io/introduction-oauth2-flow-diagrams/

wprowadź opis zdjęcia tutaj

Każdy z nich ma inny poziom trudności implementacji, bezpieczeństwa i przypadków użycia. W zależności od potrzeb i sytuacji będziesz musiał użyć jednego z nich. Którego użyć?

Poświadczenie klienta : jeśli Twoja aplikacja obsługuje tylko jednego użytkownika

Crendential Hasło właściciela zasobów : należy go używać tylko w ostateczności, ponieważ użytkownik musi przekazać swoje poświadczenia aplikacji, co oznacza, że ​​aplikacja może zrobić wszystko, co użytkownik może

Kod autoryzacji : najlepszy sposób na uzyskanie autoryzacji użytkownika

Domniemany : jeśli twoja aplikacja jest mobilna lub jednostronicowa

Więcej wyjaśnień wyboru tutaj: https://blog.oauth.io/choose-oauth2-flow-grant-types-for-app/

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.