Dlaczego OAuth v2 ma zarówno tokeny dostępu, jak i odświeżania?

654

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?

Dave Mankoff
źródło

Odpowiedzi:

463

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.)

catchdave
źródło
14
Catchdave ma rację, ale pomyślałem, że dodam, że wszystko zmieniło się od czasu jego pierwszej odpowiedzi. Korzystanie z SSL jest teraz opcjonalne (prawdopodobnie było to wciąż przedmiotem dyskusji, gdy catchdave odpowiedział). Na przykład tokeny MAC (obecnie w fazie rozwoju) zapewniają możliwość podpisania żądania za pomocą klucza prywatnego, dzięki czemu SSL nie jest wymagany. Odświeżanie tokenów staje się zatem bardzo ważne, ponieważ chcesz mieć krótkotrwałe tokeny mac.
AlexGad
54
„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”. Ale identyfikator klienta i sekret są również przechowywane w urządzeniu, prawda? Atakujący z dostępem do urządzenia może je zdobyć. To dlaczego? Tutaj, github.com/auth0/lock/wiki/Using-a-Refresh-Token , napisano, że utrata tokenu Odświeżania oznacza, że ​​może on żądać tylu tokenów autoryzacji , ile chce, może nie być w scenariuszu Google, ale co jeśli wdrażam własny serwer oauth2?
Jamsheed Kamarudeen
42
„Aby uzyskać token dostępu, atakujący wymaga identyfikatora klienta i tajnego klucza oprócz tokenu odświeżania” : jaka jest zatem różnica między używaniem tokenu odświeżania a po prostu rezygnacją?
sp00m
34
Token odświeżania może być używany przez firmę zewnętrzną, która może odnowić token dostępu bez znajomości poświadczeń użytkownika.
Marek Gru
27
@KevinWheeler Nie, identyfikator klienta i klucz tajny są poświadczeniami klienta OAuth, a nie użytkownika. Mówiąc o OAuth, „klientem” jest zazwyczaj serwer (na przykład serwer WWW stackoverflow), który współpracuje z serwerem API autoryzacji lub zasobów (na przykład dostawca autoryzacji Facebook). Poświadczenia użytkownika są przekazywane tylko między użytkownikiem a serwerem API OAuth i nigdy nie są znane klientowi. Sekret klienta jest przekazywany tylko od klienta do serwera API OAuth i nigdy nie jest znany użytkownikowi.
maszyna tęskni
551

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.

  1. Okno". Przedział czasu między zdarzeniami „użytkownik odwołuje dostęp” i „dostęp jest gwarantowany, że zostanie odwołany”.

  2. Komplikacja logiki klienta.

    bez tokena odświeżania

    • wysłać zapytanie API z tokenem dostępu
    • jeśli token dostępu jest nieprawidłowy, nie powiod się i poproś użytkownika o ponowne uwierzytelnienie

    z tokenem odświeżania

    • wysłać zapytanie API z tokenem dostępu
    • Jeśli token dostępu jest nieprawidłowy, spróbuj zaktualizować go przy użyciu tokena odświeżania
    • jeśli żądanie odświeżenia mija, zaktualizuj token dostępu i ponownie wyślij początkowe żądanie API
    • Jeśli żądanie odświeżenia nie powiedzie się, poproś użytkownika o ponowne uwierzytelnienie

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.

Roman Imankulov
źródło
4
@RomannImankulov Jeśli rozumiem, że poprawnie odświeża token, możemy zapisać go w db i usunąć je za każdym razem, gdy chcemy odwołać dostęp, więc dlaczego nie zapisać tokenów acces samodzielnie?
kosnkov,
30
@kosnkov krótka wersja mojego postu jest taka, że ​​jeśli zapiszesz token dostępu w bazie danych, trafisz do bazy danych przy każdym żądaniu do twojego API (co może, ale nie musi być problemem w twoim przypadku). Jeśli zapiszesz tokeny odświeżania i utrzymasz tokeny dostępu „samodzielnie”, trafisz do bazy danych tylko wtedy, gdy klient zdecyduje się odświeżyć token dostępu.
Roman Imankulov
5
Osobiście nie podoba mi się to podejście polegające na nie uderzaniu w bazę danych w celu zwiększenia wydajności, jeśli ma ona zagrozić bezpieczeństwu (nawet jeśli tylko na czas okna). W razie potrzeby należy natychmiast odwołać token_dostępu, ponieważ prawie zawsze mamy do czynienia z poufnymi informacjami użytkownika (w przeciwnym razie prawdopodobnie nie korzystalibyśmy z OAuth). Zastanawiam się, które podejście wykorzystują większe firmy, takie jak Facebook i Google.
Tiago,
1
Nie do końca rozumiem, dlaczego musimy mieć „okno otwarte” przez jakiś czas. Dlaczego nie możemy po prostu wysłać żądania do serwera zasobów, aby nie akceptować tokenów dostępu dla tego użytkownika? Czy mam również rację, że nie można zachować działania tokena odświeżającego, gdy nie ma tajnego klienta do podpisywania tokenów? Zasadniczo nie można używać tokenów odświeżania z oprogramowania na urządzeniach cliemts js, aplikacjach mobilnych itp.
Igor Čordaš
1
@PSIXO serwer zasobów nie ma żadnego trwałego magazynu oprócz bazy danych i być może lokalnej pamięci podręcznej. Dlatego jedynym sposobem sprawdzenia, czy token został odwołany, jest trafienie do bazy danych, a tego próbuje uniknąć cały ten proces. Jeśli chodzi o twoje drugie pytanie, nie masz racji. Jeśli masz token odświeżania, możesz poprosić o nowe tokeny dostępu.
bernie,
199

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ń.

  1. 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.

  2. 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.

  3. 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.

laalaguer
źródło
@laalaguer Czy masz jakieś bardziej szczegółowe zasady, takie jak na przykład: Nie odwoływać tokena, gdy zmieni się adres IP użytkownika (gdy telefon komórkowy rozłącza się z Wi-Fi i łączy się z siecią 3G / 4G)?
svlada,
65
Oto kilka świetnych zasad i pomysłów, ale nie widzę w twojej odpowiedzi niczego, co z natury wymagałoby użycia tokenów odświeżania. Wszystkie te funkcje można wdrożyć za pomocą tokena dostępu.
Evert,
12
@Evert, jedną z korzyści używania zarówno tokenów dostępu, jak i odświeżania jest to, że tokeny dostępu mogą być krótkotrwałe i dlatego nie jest zbyt dużym zagrożeniem bezpieczeństwa, aby ufać im bezwarunkowo bez sprawdzania z serwerem, który je pierwotnie wydał. Dzięki temu można skalować infrastrukturę, aby niekrytyczne jej części mogły ufać informacjom przechowywanym w (podpisanym) tokenie bez bezpośredniego dostępu do informacji o koncie użytkownika.
Avi Cherry,
7
@Avi Cherry - Tak, token dostępu może być krótkotrwały, a także można go odświeżyć, jeśli użytkownik nadal jest uważany za ważny. W tym celu nie wymaga tokena odświeżania.
Rick Jolly
10
Uważam, że ta odpowiedź zakłada, że ​​nigdy nie chcemy, aby serwery zasobów same wykonywały zaawansowaną kontrolę dostępu (np. Sprawdzają aktywność IP w różnych bazach danych itp.), A zamiast tego mogą polegać jedynie na weryfikacji tokena dostępu w całkowitej izolacji. Chociaż może to być oczywiste w skali (ze względu na wydajność), nie jest to oczywiste dla wszystkich tutaj, biorąc pod uwagę zamieszanie w innych postach i komentarzach. To dobry post z miłą informacją, ale wydaje mi się, że znacznie pomija sens pierwotnego pytania. Zalecam przynajmniej wyraźne sformułowanie powyższego założenia.
wtorek
72

Ż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.

BT
źródło
16
Jest to interesujące, ponieważ w przypadku Google, gdy poprosisz o token odświeżania, wysyłasz także identyfikator klienta i klucz tajny klienta. Tak czy inaczej, kompromitujesz się co godzinę.
Rots
1
Alexander, w rzeczywistości im krótszy jest ttl, tym częściej klient będzie musiał uzyskać nowy token dostępu (co wymaga użycia poświadczeń klienta). Tak naprawdę mam na myśli „krótszy”. Dodam notatkę, aby wyjaśnić.
BT
2
„wyłączny cel” - nie myje się. Wykonanie TTL tokena dostępu tak długo, jak wyimaginowanego tokena odświeżania osiągnie to samo.
Rhubarb
8
Ponieważ standard wymaga, aby poświadczenia klienta były wysyłane wraz z tokenem odświeżania, przesłanka tej odpowiedzi jest po prostu fałszywa. „Ponieważ tokeny odświeżania są zwykle długotrwałymi poświadczeniami używanymi do żądania dodatkowych tokenów dostępu ... klient MUSI uwierzytelnić się na serwerze autoryzacji”. Zobacz także komentarz @Rots.
Kevin Christopher Henry
8
A) Myślę, że mieszasz tajemnice klienta i tajemnice użytkownika. Klucz tajny klienta nigdy nie jest wysyłany z urządzenia użytkownika, tylko z dostępu do aplikacji zaplecza do danych udostępniających aplikację zaplecza. B) Serwer oAuth, który zezwala na przyznanie hasła dla klienta publicznego (klienta, który nie może utrzymywać w tajemnicy klienta, takiego jak aplikacja natywna lub javascript), również zapewni grant odświeżania tokena dla tego klienta publicznego, dlatego nie trzeba wyślij sekret klienta podczas odświeżania tokena. C) Token odświeżania zapewnia backendowi „hart-beat”, kiedy należy sprawdzić ważność użytkownika!
Andreas Lundgren,
55

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:

  • ID użytkownika
  • Hasło użytkownika
  • Identyfikator klienta
  • Sekret klienta

Aby uzyskać odświeżony token dostępu, klient korzysta z następujących informacji:

  • Identyfikator klienta
  • Sekret klienta
  • Token odświeżania

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 .

Przeciwny
źródło
1
„To pokazuje również, że utrata tokena odświeżania nie stanowi problemu, ponieważ identyfikator klienta i klucz tajny nie są znane”. Ale ja ich nie potrzebuję. Jeśli dostanę token odświeżania, mogę przekazać go do serwera aplikacji. Dodaje client_id i secret, a następnie przekazuje wszystkie trzy do usługi OAuth. Jaki jest sens?
3DFace
7
Serwer aplikacji nie zapewnia sposobu samodzielnego dostarczenia tokena odświeżającego, nie można poprosić go o wygenerowanie nowego tokena uwierzytelniającego, podając mu token odświeżający. W razie potrzeby odnawia sam token uwierzytelniania „za kulisami”.
Adversus
2
Pamiętaj, że tak naprawdę potrzebujesz klucza tajnego klienta, aby uzyskać token odświeżania. Być może myślisz o niejawnym procesie uwierzytelniania, w którym nie potrzebujesz sekretu, ale tokeny odświeżania nie są wydawane ani używane w takim przypadku.
Kevin Christopher Henry
@KevinChristopherHenry tego rodzaju sugeruje, że dla użytkownika końcowego, który loguje się na stronie firmowej XYZ.com, token odświeżania nie ma sensu, aby uzyskać nowy token dostępu dla XYZ.com? Ale token odświeżania może być dowolnym ciągiem, którego nie można zgadnąć - jak guid - przechowywanym w tabeli, którą można bardzo szybko wyszukać. Natomiast token dostępu może być znacznie dłuższy i trudniejszy do indeksowania w bazie danych. Tak więc token odświeżania MOŻE być przechowywany i ma zalety po stronie użytkownika końcowego. [chociaż skoro to pytanie mówi o oauth2, być może żadne odpowiedzi bez usługi strony trzeciej działającej w imieniu osoby i tak nie są istotne]
Simon_Weaver
dlaczego nie możesz po prostu przekazać „Identyfikatora klienta” + „Tajny klucz klienta” + „wygasł token dostępu”, aby uzyskać nowy token dostępu?
Honey
37

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/

Manicode
źródło
Wydaje się, że dotyczy to OpenID Connect i uwierzytelniania, więc nie rozumiem, jak to odpowiada na pytanie, które dotyczy motywacji do odświeżenia tokena.
śleske
18

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?

Phil
źródło
2
„Odśwież tokeny pozwalają tylko na ponowne uwierzytelnienie klienta ...” jest tutaj ważnym aspektem.
James
13

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.

heymega
źródło
4
Umieszczanie takich „roszczeń” w tokenie dostępu byłoby nietypową złą praktyką. Jak opisano w specyfikacji , token dostępu „jest zwykle nieprzezroczysty dla klienta”. Czy masz przykłady dostawców OAuth, którzy to robią?
Kevin Christopher Henry
3
@heymega Gdy rola użytkownika zostanie obniżona z ADMIN do REGULAR_USER, oczekuje się, że rola użytkownika musi zostać natychmiast odwołana, a nie po wygaśnięciu tokenu dostępu. Wygląda więc na to, że trafienie do bazy danych przy każdym żądaniu jest nieuniknione.
svlada
@svlada Wyobrażam sobie, że byłby to przypadek, w którym aplikacja obniżająca jednostkę z ADMIN do REGULAR_USER musiałaby (w tym samym procesie) również odwołać odpowiedni token. tzn. jeśli wiemy, że roszczenia zmienią się, nie czekamy na wygaśnięcie, natychmiast
odwołujemy
13

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.

bitcoder
źródło
1
Możesz odwołać token dostępu, który będzie wymagał albo ponownego zalogowania się na inny token dostępu, albo użycia tokena odświeżania w celu uzyskania kolejnego tokenu dostępu. Jeśli token odświeżania był nieprawidłowy, użytkownik będzie musiał ponownie uwierzytelnić się, aby otrzymać nowy token dostępu wraz z nowym tokenem odświeżania.
Atieh
10
Nie zgadzam się. Token dostępu jest wydawany przez serwer autoryzacji, podpisany datą ważności i wysyłany do klienta. Gdy klient wysyła ten token do serwera zasobów, serwer zasobów nie kontaktuje się z serwerem autoryzacji w celu weryfikacji tokena; po prostu patrzy na datę ważności tokena (podpisanego i niezakłóconego). Więc bez względu na to, co robisz na serwerze uwierzytelniania, aby spróbować „odwołać”, serwer zasobów nie dba o to. Niektóre osoby odnoszą się do wylogowania klienta jako odwołania (tj. Klient usuwa swój token), ale imho jest to myląca terminologia - chcemy „odwołać” token na serwerze, a nie na kliencie
bitcoder
1
Nie oznacza to, że nie można napisać niestandardowego kodu, aby zignorować niektóre tokeny (jak tutaj stackoverflow.com/questions/22708046/… ), ale wykonanie tego prawdopodobnie wiąże się z pewnymi wycieczkami sieciowymi z serwera zasobów do serwera / db auta za każdym razem, gdy klient robi połączenie Unikaj tych połączeń, używając zamiast tego tokenów odświeżania, i myślę, że jest to bardziej zgodne z zamierzeniami autorów.
bitcoder
13

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

miód
źródło
2
trudno jest śledzić to porównanie, ponieważ pytania są różne 1. „W ciągu 30 minut, ile możliwości hakerskich miałem przeciwko kluczowi?” (czy najpierw nie miałem klucza jako hakera?) 2. „Ile w ciągu 30 minut miałem okazji do włamania się do kuriera?”. Jaka byłaby „okazja do włamania”? Czy jako haker przede wszystkim nie miałem klucza?
Cesc,
1
Masz rację. Wprowadziłem zmiany
Kochanie,
4

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.

Tạ Anh Tú
źródło
2
„przy użyciu nie tylko tokena_odświeżania, ale także przez client_id i client_secret, których haker nie ma.” 1. Załóżmy, że jest to tylko token dostępu, więc czy haker nadal nie potrzebuje client_id i client_secret? 2. Jeśli haker jest dobrym hakerem, może również zhakować identyfikator_użytkownika i identyfikator_klienta. Niezależnie od tej części, hackowanie dodatkowych rzeczy nie powinno mieć znaczenia dla porównania, ponieważ jeśli trudno jest hakować, to również trudno jest hakować w przypadku użycia tylko tokena dostępu ... krótko mówiąc, nie porównujesz identycznych sytuacji. Mieszacie je
Honey,
2

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.

Kraming
źródło
Myślę, że to bardzo ważna kwestia :-) To także - do pewnego stopnia - w pewnym stopniu unieważnia argument tutaj auth0.com/docs/tokens/refresh-token/current#restrictions, żeA 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.
Simon_Weaver
1

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.

Saptarshi Basu
źródło
0

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.


źródło
To tak naprawdę nie wspomina, skąd pochodzi token odświeżania. Zakładam, że drugi akapit powinien powiedzieć access token + refresh token?
Simon_Weaver