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

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?

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.

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.

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:
   

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

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

4. Teraz LinkedIn może uzyskać dostęp do moich kontaktów w Gmailu:

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

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 .

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 ---|               |
     +--------+                               +---------------+

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

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.

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

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/

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/