Sekcja 4.2 projektu protokołu OAuth 2.0 wskazuje, że serwer autoryzacji może zwrócić zarówno access_token(używany do uwierzytelnienia się w zasobie), jak i taki refresh_token, który służy wyłącznie do utworzenia nowego access_token:
https://tools.ietf.org/html/rfc6749#section-4.2
Dlaczego oba? Dlaczego nie zrobić access_tokenostatniego tak długo, jak refresh_tokennie ma refresh_token?
Odpowiedzi:
Idea tokenów odświeżania polega na tym, że jeśli token dostępu zostanie naruszony, ponieważ jest krótkotrwały, atakujący ma ograniczone okno, w którym można go wykorzystać.
Tokeny odświeżania, jeśli są zagrożone, są bezużyteczne, ponieważ atakujący wymaga identyfikatora klienta i hasła oprócz tokena odświeżania, aby uzyskać token dostępu.
Powiedziawszy to , ponieważ każde wywołanie zarówno do serwera autoryzacji, jak i serwera zasobów odbywa się za pośrednictwem protokołu SSL - w tym oryginalnego identyfikatora klienta i hasła, gdy żądają tokenów dostępu / odświeżania - nie jestem pewien, w jaki sposób token dostępu jest już „ kompromis ”niż długo działający token odświeżania i klient / tajna kombinacja.
To oczywiście różni się od implementacji, w których nie kontrolujesz zarówno serwera autoryzacji, jak i serwerów zasobów.
Oto dobry wątek mówiący o zastosowaniu tokenów odświeżania: Archiwa OAuth .
Cytat z powyższego, mówiący o celach bezpieczeństwa tokena odświeżania:
Odśwież tokeny ... zmniejsza ryzyko długotrwałego wycieku tokenu dostępu (parametr zapytania w pliku dziennika na niepewnym serwerze zasobów, w wersji beta lub źle zakodowanej aplikacji serwera zasobów, klient JS SDK w witrynie innej niż https, która umieszcza token dostępu w ciasteczko itp.)
Link do dyskusji, dostarczony przez Catchdave, ma jeszcze jeden ważny punkt (oryginalny, martwy link) autorstwa Dicka Hardta, który moim zdaniem powinien zostać tutaj wymieniony oprócz tego, co napisano powyżej:
Przypomniałem sobie tokeny odświeżania dla bezpieczeństwa i odwołania. <...>
unieważnienie: jeśli token dostępu jest samowystarczalny, autoryzację można cofnąć, nie wydając nowych tokenów dostępu. Zasób nie musi sprawdzać serwera autoryzacji, aby sprawdzić, czy token dostępu jest prawidłowy. Upraszcza to sprawdzanie poprawności tokenu dostępu i ułatwia skalowanie i obsługę wielu serwerów autoryzacji. Istnieje okres czasu, w którym token dostępu jest ważny, ale autoryzacja zostaje cofnięta.
Rzeczywiście, w sytuacji, gdy serwer zasobów i serwer autoryzacji to ta sama jednostka, a połączenie między użytkownikiem a jednym z nich jest (zwykle) równie bezpieczne, nie ma sensu oddzielanie tokena odświeżania od tokena dostępu.
Chociaż, jak wspomniano w cytacie, inną rolą tokenów odświeżania jest zapewnienie, że token dostępu może zostać w dowolnym momencie odwołany przez użytkownika (na przykład przez interfejs internetowy w ich profilach), przy jednoczesnym utrzymaniu skalowalności systemu w tym samym czasie .
Zasadniczo tokeny mogą być losowymi identyfikatorami wskazującymi konkretny rekord w bazie danych serwera lub mogą zawierać wszystkie informacje same w sobie (z pewnością informacje te muszą być podpisane , na przykład za pomocą MAC ).
Jak powinien działać system z długowiecznymi tokenami dostępu
Serwer pozwala klientowi uzyskać dostęp do danych użytkownika w ramach predefiniowanego zestawu zakresów poprzez wydanie tokena. Ponieważ chcemy, aby token był odwołalny, musimy przechowywać w bazie danych token wraz z flagą „odwołany” ustawioną lub cofniętą (w przeciwnym razie, jak byś to zrobił z samodzielnym tokenem?) Baza danych może zawierać tyle samo, co len(users) x len(registered clients) x len(scopes combination)rekordy . Każde żądanie API musi następnie trafić do bazy danych. Chociaż zapytania do takiej bazy danych wykonujące O (1) są dość trywialne, sam pojedynczy punkt awarii może mieć negatywny wpływ na skalowalność i wydajność systemu.
Jak powinien działać system z długoterminowym tokenem odświeżania i tokenem dostępu o krótkim czasie trwania
Tutaj wydajemy dwa klucze: losowy token odświeżania z odpowiednim rekordem w bazie danych oraz podpisany samodzielny token dostępu, zawierający między innymi pole znacznika czasu wygaśnięcia.
Ponieważ token dostępu jest samowystarczalny, nie musimy wcale przeszukiwać bazy danych, aby sprawdzić jej poprawność. Wszystko, co musimy zrobić, to zdekodować token oraz zweryfikować podpis i sygnaturę czasową.
Niemniej jednak nadal musimy przechowywać bazę danych tokenów odświeżania, ale liczba żądań do tej bazy danych jest generalnie określona przez długość życia tokena dostępu (im dłuższa żywotność, tym niższa szybkość dostępu).
Aby odwołać dostęp klienta do konkretnego użytkownika, należy oznaczyć odpowiedni token odświeżania jako „odwołany” (lub całkowicie go usunąć) i przestać wydawać nowe tokeny dostępu. Oczywiste jest jednak, że istnieje okno, w którym token odświeżania został odwołany, ale jego token dostępu może być nadal ważny.
Kompromisy
Odśwież tokeny częściowo eliminują SPoF (Single Point of Failure) bazy danych Tokenów Dostępu, ale mają pewne oczywiste wady.
Okno". Przedział czasu między zdarzeniami „użytkownik odwołuje dostęp” i „dostęp jest gwarantowany, że zostanie odwołany”.
Komplikacja logiki klienta.
bez tokena odświeżania
z tokenem odświeżania
Mam nadzieję, że ta odpowiedź ma sens i pomaga komuś podjąć bardziej przemyślaną decyzję. Chciałbym również zauważyć, że niektórzy znani dostawcy OAuth2, w tym github i foursquare, przyjmują protokół bez tokenów odświeżania i wydają się z tego zadowoleni.
Pomimo wszystkich świetnych odpowiedzi powyżej, jako student i programista zabezpieczeń, który wcześniej pracował w serwisie eBay, kiedy przyglądałem się ochronie kupujących i oszustwom, mogę powiedzieć, że oddzielenie tokena dostępu i token odświeżania ma najlepszą równowagę między nękaniem użytkownika o częstej nazwie użytkownika / wprowadzenie hasła i utrzymywanie w mocy upoważnienia do cofnięcia dostępu do potencjalnego nadużycia usługi.
Pomyśl o takim scenariuszu. Wydajesz użytkownikowi token dostępu o długości 3600 sekund i odświeżasz go znacznie dłużej niż jeden dzień.
Użytkownik jest dobrym użytkownikiem, jest w domu i włącza / wyłącza Twoją witrynę, robiąc zakupy i wyszukując na swoim iPhonie. Jego adres IP nie zmienia się i ma bardzo niskie obciążenie na twoim serwerze. Jak 3-5 żądań stron co minutę. Po upływie 3600 sekund na żetonie dostępu, potrzebuje nowego z tokenem odświeżania. My, po stronie serwera, sprawdzamy jego historię aktywności i adres IP, uważamy, że jest człowiekiem i zachowuje się sam. Udzielamy mu nowego tokena dostępu, aby mógł nadal korzystać z naszej usługi. Użytkownik nie będzie musiał ponownie wprowadzać nazwy użytkownika / hasła, dopóki nie osiągnie żywotności tokena odświeżania jednego dnia.
Użytkownik jest nieostrożnym użytkownikiem. Mieszka w Nowym Jorku w USA, jego program antywirusowy został zamknięty i został zhakowany przez hakera w Polsce . Gdy haker otrzymuje token dostępu i token odświeżania, próbuje podszyć się pod użytkownika i skorzystać z naszych usług. Ale po wygaśnięciu tokenu dostępu krótkotrwałego, gdy haker próbuje odświeżyć token dostępu, my na serwerze zauważyliśmy dramatyczną zmianę adresu IP w historii zachowań użytkowników (hej, ten facet loguje się w USA, a teraz odświeża dostęp w Polsce już po 3600? Kończymy proces odświeżania, unieważniamy sam token odświeżania i monitujemy o ponowne wprowadzenie nazwy użytkownika / hasła.
Użytkownik jest złośliwym użytkownikiem. Ma on na celu nadużycie naszej usługi przez wywołanie 1000 razy naszego interfejsu API co minutę za pomocą robota. Potrafi to robić do 3600 sekund później, kiedy próbuje odświeżyć token dostępu, zauważyliśmy jego zachowanie i myślimy, że może nie być człowiekiem. Odrzucamy i kończymy proces odświeżania i prosimy go o ponowne wprowadzenie nazwy użytkownika / hasła. Może to potencjalnie przerwać automatyczny przepływ jego robota. Przynajmniej czyni go niewygodnym.
Możesz zobaczyć, że token odświeżania zadziałał idealnie, gdy próbujemy zrównoważyć naszą pracę, wrażenia użytkownika i potencjalne ryzyko skradzionego tokena. Twój pies stróżujący po stronie serwera może sprawdzić więcej niż zmianę adresu IP, częstotliwość wywołań interfejsu API, aby ustalić, czy użytkownik powinien być dobrym użytkownikiem, czy nie.
Innym słowem jest to, że możesz także spróbować ograniczyć kontrolę szkód skradzionego tokena / nadużycia usługi poprzez wdrożenie na każdym interfejsie API podstawowego psa obserwującego IP lub innych środków. Jest to jednak kosztowne, ponieważ musisz czytać i zapisywać informacje o użytkowniku i spowalnia reakcję serwera.
Żadna z tych odpowiedzi nie dotyczy podstawowego powodu, dla którego istnieją tokeny odświeżania. Oczywiście zawsze możesz uzyskać nową parę token dostępu / token odświeżania, wysyłając dane uwierzytelniające klienta do serwera uwierzytelniania - w ten sposób uzyskujesz je w pierwszej kolejności.
Tak więc jedynym celem tokenu odświeżania jest ograniczenie użycia poświadczeń klienta przesyłanych przewodowo do usługi uwierzytelniania. Im krótszy jest ttl tokena dostępu, tym częściej dane uwierzytelniające klienta będą musiały zostać użyte do uzyskania nowego tokena dostępu, a zatem im więcej okazji osoby atakujące będą musiały naruszyć dane uwierzytelniające klienta (chociaż może to być bardzo trudne, jeśli stosuje się szyfrowanie asymetryczne). Więc jeśli masz jednorazowy token odświeżania, możesz sprawić, że ttl tokenów dostępu zostanie arbitralnie mały, bez narażania poświadczeń klienta.
Aby usunąć zamieszanie, musisz zrozumieć role klucza tajnego klienta i hasła użytkownika , które są bardzo różne.
Klient jest aplikacja / strona / Program / ..., wspierane przez serwer, który chce, aby uwierzytelnić się użytkownikowi za pomocą usługi uwierzytelniania innej firmy. Sekret klienta jest (losowym) ciągiem znanym zarówno temu klientowi, jak i serwerowi uwierzytelniania. Korzystając z tego tajnego klucza, klient może identyfikować się z serwerem uwierzytelniającym, otrzymując autoryzację do żądania tokenów dostępu.
Aby uzyskać początkowy token dostępu i odświeżyć token, wymagane jest:
Aby uzyskać odświeżony token dostępu, klient korzysta z następujących informacji:
To wyraźnie pokazuje różnicę: podczas odświeżania klient otrzymuje autoryzację do odświeżenia tokenów dostępu przy użyciu swojego klucza tajnego, a zatem może ponownie uwierzytelnić użytkownika przy użyciu tokena odświeżania zamiast identyfikatora użytkownika + hasła. To skutecznie zapobiega konieczności ponownego wprowadzania hasła przez użytkownika.
Pokazuje to również, że utrata tokena odświeżania nie stanowi problemu, ponieważ identyfikator klienta i klucz tajny nie są znane. Pokazuje również, że utrzymanie identyfikatora klienta i tajnego klucza klienta jest kluczowe .
Ta odpowiedź pochodzi od Justina Richera za pośrednictwem standardowej listy e-mail OAuth 2. Jest to publikowane za jego zgodą.
Żywotność tokena odświeżania zależy od serwera autoryzacji (AS) - mogą wygasnąć, zostać odwołane itp. Różnica między tokenem odświeżania a tokenem dostępu polega na odbiorców: token odświeżania wraca tylko na serwer autoryzacji, token dostępu trafia do serwera zasobów (RS).
Również samo uzyskanie tokena dostępu nie oznacza, że użytkownik jest zalogowany. W rzeczywistości użytkownik może nawet tam nie być, co w rzeczywistości jest zamierzonym przypadkiem użycia tokena odświeżania. Odświeżenie tokena dostępu da ci dostęp do interfejsu API w imieniu użytkownika, nie powie ci, czy użytkownik tam jest.
OpenID Connect nie tylko podaje informacje o użytkowniku z tokena dostępu, ale także token ID. Jest to oddzielna część danych skierowana do samego klienta, a nie do AS lub RS. W OIDC powinieneś brać pod uwagę kogoś, kto faktycznie „zalogował się” przez protokół, jeśli możesz dostać nowy token identyfikacyjny. Odświeżenie prawdopodobnie nie wystarczy.
Aby uzyskać więcej informacji, przeczytaj http://oauth.net/articles/authentication/
Klienci mogą być narażeni na wiele sposobów. Na przykład można sklonować telefon komórkowy. Wygaśnięcie tokena dostępu oznacza, że klient jest zmuszony do ponownego uwierzytelnienia na serwerze autoryzacji. Podczas ponownego uwierzytelnienia serwer autoryzacji może sprawdzić inne cechy (IOW wykonuje adaptacyjne zarządzanie dostępem).
Odśwież tokeny pozwalają klientowi tylko na ponowne uwierzytelnienie, przy czym w przypadku ponownej autoryzacji wymusza dialog z użytkownikiem, którego wielu wskazało, że raczej tego nie zrobi.
Tokeny odświeżające mieszczą się zasadniczo w tym samym miejscu, w którym normalne strony internetowe mogą okresowo uwierzytelniać użytkowników po około godzinie (np. Strona bankowa). Obecnie nie jest powszechnie używany, ponieważ większość serwisów społecznościowych nie uwierzytelnia użytkowników, więc dlaczego mieliby ponownie uwierzytelniać klienta?
Dlaczego po prostu nie sprawić, by access_token trwał tak długo, jak odświeżony_token i nie miałby_token_odświeżania?
Oprócz wspaniałych odpowiedzi udzielonych przez inne osoby istnieje jeszcze jeden powód, dla którego warto używać tokenów odświeżania i ma to związek z roszczeniami.
Każdy token zawiera oświadczenia, które mogą obejmować wszystko od nazwy użytkownika, jego roli lub dostawcy, który utworzył oświadczenie. W trakcie odświeżania tokena roszczenia są aktualizowane.
Jeśli odświeżamy tokeny częściej, oczywiście obciążamy nasze usługi tożsamości, jednak otrzymujemy dokładniejsze i aktualne roszczenia.
Aby jeszcze bardziej uprościć odpowiedź BT: Użyj tokenów odświeżania, jeśli zwykle nie chcesz, aby użytkownik musiał ponownie wpisać poświadczenia, ale nadal chcesz, aby moc mogła odwołać uprawnienia (przez odwołanie tokena odświeżania)
Nie możesz odwołać tokena dostępu, tylko token odświeżania.
Ta odpowiedź została zebrana dzięki pomocy dwóch starszych deweloperów (John Brayton i David Jennes).
Głównym powodem użycia tokena odświeżającego jest zmniejszenie powierzchni ataku.
Załóżmy, że nie ma klucza odświeżania i przejdźmy do tego przykładu:
Budynek ma 80 drzwi. Wszystkie drzwi są otwierane za pomocą tego samego klucza. Klucz zmienia się co 30 minut. Pod koniec 30 minut muszę przekazać kluczowi stary klucz i zdobyć nowy.
Jeśli jestem hakerem i zdobędę twój klucz, to pod koniec 30 minut przekażę go do klucza i zdobędę nowy klucz. Będę mógł ciągle otwierać wszystkie drzwi bez względu na zmianę klucza.
Pytanie: Ile miałem okazji włamać się do klucza w ciągu 30 minut? Miałem 80 okazji do hakowania za każdym razem, gdy używałeś klucza (pomyśl o tym jak o wysłaniu żądania sieciowego i przekazaniu tokena dostępu w celu identyfikacji). To 80-krotna powierzchnia ataku.
Przejdźmy teraz do tego samego przykładu, ale tym razem załóżmy, że jest klawisz odświeżania.
Budynek ma 80 drzwi. Wszystkie drzwi są otwierane za pomocą tego samego klucza. Klucz zmienia się co 30 minut. Aby uzyskać nowy klucz, nie mogę przekazać starego tokena dostępu. Muszę tylko przekazać klucz odświeżania.
Jeśli jestem hakerem i zdobędę twój klucz, mogę go używać przez 30 minut, ale pod koniec 30 minut wysłanie go do klucza nie ma żadnej wartości. Jeśli to zrobię, kluczowy klucz powie po prostu ten zły token odświeżania. Aby móc przedłużyć mój hack, musiałbym zhakować kuriera do klucza. Kurier ma wyraźny klucz (pomyśl o tym jak o tokenie odświeżającym).
Pytanie: Ile możliwości hakowania miałem w ciągu 30 minut w stosunku do klucza odświeżania? 80? Nie. Miałem tylko 1 okazję do włamania. W tym czasie kurier komunikuje się z kluczowcem. To 1X powierzchnia ataku. Miałem 80 okazji hakowania przeciwko kluczowi, ale po 30 minutach nie są one dobre.
Serwer zweryfikuje token dostępu na podstawie poświadczeń i podpisania (zwykle) JWT.
Wyciekanie tokena dostępu jest złe, ale gdy wygasa, nie jest już przydatne dla atakującego. Wyciekanie tokenu odświeżania jest znacznie gorsze, ale przypuszczalnie mniej prawdopodobne. (Myślę, że jest miejsce na pytanie, czy prawdopodobieństwo wycieku tokena odświeżającego jest znacznie niższe niż wycieku tokenu dostępowego, ale taki jest pomysł).
Chodzi o to, że token dostępu jest dodawany do każdego złożonego żądania, podczas gdy token odświeżania jest używany tylko podczas przepływu odświeżania, więc mniejsza szansa, że MITM zobaczy token
Częstotliwość pomaga atakującemu. Heartbleed - potencjalne wady bezpieczeństwa w SSL, potencjalne wady bezpieczeństwa u klienta i potencjalne wady bezpieczeństwa na serwerze umożliwiają wyciek.
Ponadto, jeśli serwer autoryzacji jest oddzielny od serwera aplikacji przetwarzającego inne żądania klienta, ten serwer aplikacji nigdy nie zobaczy tokenów odświeżania. Zobaczy tylko tokeny dostępu, które nie będą dłużej działać.
Podział na przedziały zapewnia bezpieczeństwo.
Na koniec zobacz tę niesamowitą odpowiedź
O czym NIE jest token odświeżania?
Możliwość aktualizacji / odwołania poziomu dostępu za pomocą tokenów odświeżania jest produktem ubocznym wyboru użycia tokenów odświeżania, w przeciwnym razie samodzielny token dostępu może zostać odwołany lub zmodyfikowany jego poziom dostępu po wygaśnięciu, a użytkownicy otrzymają nowy token
Załóżmy, że robisz to access_tokenbardzo długo, a nie masz refresh_token, więc w ciągu jednego dnia haker to zdobędzieaccess_token i będzie mógł uzyskać dostęp do wszystkich chronionych zasobów!
Ale jeśli tak refresh_token, access_tokenczas na żywo jest krótki, więc hakerowi trudno jest zhakować twój, access_tokenponieważ po krótkim czasie będzie on nieważny.
Access_tokenmożna je odzyskać, używając nie tylko, refresh_tokenale także client_idi client_secret, którego haker nie ma.
Podczas gdy token odświeżania jest zachowywany przez serwer autoryzacji. Token dostępu jest samowystarczalny, więc serwer zasobów może go zweryfikować bez zapisywania, co oszczędza wysiłku wyszukiwania w przypadku sprawdzania poprawności. Kolejnym brakującym punktem w dyskusji jest z rfc6749 # page-55
„Na przykład serwer autoryzacji może zastosować rotację tokenu odświeżania, w której wydawany jest nowy token odświeżania przy każdej odpowiedzi na odświeżenie tokena dostępu. Poprzedni token odświeżania jest unieważniany, ale zachowywany przez serwer autoryzacji. Jeśli token odświeżania zostanie przejęty, a następnie wykorzystany przez zarówno atakujący, jak i legalny klient, jeden z nich przedstawi unieważniony token odświeżania, który poinformuje serwer autoryzacji o naruszeniu. ”
Myślę, że cały sens używania tokenu odświeżania polega na tym, że nawet jeśli atakującemu uda się uzyskać token odświeżania, identyfikator klienta i tajną kombinację. Przy kolejnych wywołaniach, aby uzyskać nowy token dostępu od atakującego, można śledzić na wypadek, gdyby każde żądanie odświeżenia skutkowało nowym tokenem dostępu i tokenem odświeżania.
A Single-Page Application (normally implementing Single-Page Login Flow) should not under any circumstances get a Refresh Token. The reason for that is the sensitivity of this piece of information. You can think of it as user credentials, since a Refresh Token allows a user to remain authenticated essentially forever. Therefore you cannot have this information in a browser, it must be stored securely.
Rozważmy system, w którym każdy użytkownik jest powiązany z jedną lub większą liczbą ról, a każda rola jest powiązana z jedną lub większą liczbą uprawnień dostępu. Informacje te mogą być buforowane w celu zwiększenia wydajności interfejsu API. Mogą jednak nastąpić zmiany w konfiguracji użytkownika i roli (np. Może zostać przyznany nowy dostęp lub bieżący dostęp może zostać odwołany), co powinno zostać odzwierciedlone w pamięci podręcznej.
W tym celu możemy używać tokenów dostępu i odświeżania. Po wywołaniu interfejsu API z tokenem dostępu serwer zasobów sprawdza pamięć podręczną pod kątem praw dostępu. JEŚLI pojawią się jakiekolwiek nowe uprawnienia dostępu, nie jest to natychmiast odzwierciedlane. Po wygaśnięciu tokena dostępu (powiedzmy za 30 minut), a klient użyje tokenu odświeżania do wygenerowania nowego tokena dostępu, pamięć podręczną można zaktualizować o zaktualizowane informacje o prawach dostępu użytkownika z bazy danych.
Innymi słowy, możemy przenieść kosztowne operacje z każdego wywołania API przy użyciu tokenów dostępu do zdarzenia generowania tokenów dostępu za pomocą tokenu odświeżania.
Po pierwsze, klient uwierzytelnia się na serwerze autoryzacji, udzielając zezwolenia.
Następnie klient żąda od serwera zasobów chronionego zasobu, podając token dostępu.
Serwer zasobów sprawdza poprawność tokena dostępu i zapewnia chroniony zasób.
Klient wysyła żądanie chronionego zasobu do serwera zasobów, przyznając token dostępu, w którym serwer zasobów sprawdza go i obsługuje żądanie, jeśli jest poprawne. Ten krok jest powtarzany do momentu wygaśnięcia tokena dostępu.
Jeśli token dostępu wygasa, klient uwierzytelnia się na serwerze autoryzacji i żąda nowego tokena dostępu, podając token odświeżania. Jeśli token dostępu jest nieprawidłowy, serwer zasobów odsyła do klienta odpowiedź o błędnym tokenie.
Klient uwierzytelnia się na serwerze autoryzacji, przyznając token odświeżania.
Serwer autoryzacji sprawdza następnie token odświeżania, uwierzytelniając klienta i wydaje nowy token dostępu, jeśli jest on ważny.
access token + refresh token?