Zrozumienie refresh token

1

Przeczytałem sporo artykułów z różnej maści grafami i prezentacjami, ale nie mogę sobie jakoś poukładać jak działa refresh token.
A w zasadzie jak on ma zminimalizować ryzyko nieautoryzowanego dostępu.

Z tego co zrozumiał z przeczytanych artykułów to:

  1. Klient dostaje Access Token z krótką datą ważności.
  2. Klient podczas żądania dostępu do strzeżonego zasobu po wygaśnięciu daty ważności tokenu dostaje status 401.
  3. Przy kolejnym żądaniu niby klient otrzymuje nowy Refresh Token z dłuższą datą ważności.

Ale niby, że jak? Wystawiany jest dodatkowy endpoint w API, który weryfikuje czy klient posiada Access Token i generuje nowy Refresh Token, który posiada te same uprawnienia do zasobów co Access Token? Przecież to bez sensu. Tak samo może ktoś przechwycić Refresh Token jak i Access Token. Nie lepiej po prostu dawać dłuższy czas wygaśnięcia dla Access Token?
Później klient uwierzytelnia się za pomocą Refresh Token? Po co w zasadzie mu wtedy pierwotny Access Token?
Ktoś może mi to jakoś łopatologicznie wyjaśnić?

1

Cóż, jedyna zaleta jaką dostrzegam z użycia dwóch tokenów o różnym czasie życia, krótkim AT i długim RT. To taka że tego o długim RT będziemy przetwarzać znacznie mniej razy niż ten o krótkim AT (RT przetwarzamy jak wygaśnie AT), a co za tym idzie ten cały proces przetwarzania tokena będzie mógł być dłuższy bez uszczerbku dla wydajności systemu. I np w tym procesie przetwarza długiego tokena RT możemy np sprawdzić czy nie został cofnięty w bazie. Dzięki temu przetwarzanie AT będzie sprowadzone do minimum, tylko sprawdzenie sumy kontrolnej.

1

Osobisce sam mam pewne watpliwosci co do dzialania tokenow takze nie traktuj mojego posta przesadnie powaznie no ale widze to tak:

Klient dostaje Access Token z krótką datą ważności.
Krotki to dosyc wzgledne pojecie takze raczej patrzylbym na to z perspektywy ze access token nie moze miec dluzszego czasu zycia od refresh tokena bo wtedy calosc raczej traci sens.

Klient podczas żądania dostępu do strzeżonego zasobu po wygaśnięciu daty ważności tokenu dostaje status 401.
No to powinienes uzyskiwac raczej bez wzgledu na to czy udostepniasz resfresh tokena czy nie.

Przy kolejnym żądaniu niby klient otrzymuje nowy Refresh Token z dłuższą datą ważności.
No tego nie do konca rozumiem. To znaczy pewnie mozna jak najbardziej cos takiego zaimplementowac. Tylko raczej nie widze sensu aby czas zycia zwiekszal sie z kazdym zalogowaniem uzytkownika. Raczej widzialbym to jako stala wartosc.

Zasadniczo wydaje mi sie ze refresh token nie ma nic wspolnego z minimalizowaniem nieautoryzowanego dostepu (no chyba ze patrzymy na to przez pryzmat krotszego czasu zycia access tokena,a co za tym idzie potencjalnie mniejsza ilosc operacji jaka ktos moze wykonac przy jego uzyciu w przypadku jego utrarty) a raczej z polepszeniem tzw user experience. Czyli klient nie musi co chwile strzelac w jakiegos sign_in a dostaje nowy access token w ramach posiadania refresh tokena (oczywiscie w przy uwzglednieniu faktu ze czas refresh tokena nie ulegl przedawnieniu).
Czyli flow wyglada mniej wiecej:

  1. User loguje sie z loginem i passwordem.
  2. Api generuje access tokena z refresh tokenem. Tego drugiego raczej bym chcial jakos sledzic aby w skrajnym przypadku wrzucic go na jakas blackliste.(DB albo jakis Redis ?)
  3. Teraz po stronie klienta:
    a) Jesli access token jest wciaz zywy to wszyscy sa szczesliwi.
    b) Jesli access token jest martwy ale mamy refresh tokena to dostajemy nowego access tokena z refresh tokenem i znowu wszyscy sa szczesliwi.
    c) Jesli access token jest martwy i refresh token jest martwy no to kaput. Logujemy sie ponownie.
0

Ok. Zaczaiłem. Dzięki.

0

Co sądzicie o odnawianiu JWT po każdym requescie do endpointa wymagającego uwierzytelnienia? takie odnowienie żywotności tokena

trzeba byłoby trochę middleware przerobić, ale czy ma to sens? na wydajność chyba to znacznie nie wpłynie

0

@WeiXiao a nie dostales jakiegos expiration date jak otrzymywales tokeny? Jesli dostales to lepiej z tego korzystac, opcjonalnie jesli wiesz ile czasu jest wazny to estymowac. Jesli nic nie wiesz to ja bym czekal na error i sprobowal jeszcze raz po odnowieniu

0

@krwq:

dostaje dostaje, ale badam różne podejścia.

Myślałem, aby np. wystawiać token na 1h, a co 15min odnawiać token, a stary dezaktywować.

4

100x łatwiej i bezpieczniej jest trzymać te małe metadane (typu długość ważności sesji czy ID użytkownika) po stronie backendu w jakimś key-store value typu Redis. Na poważnie wzięte bezpieczeństwo i tak wymaga stanu po stronie serwera (np ograniczanie liczby otwartych sesji dla jednego użytkownika, opcja wylogowania z innych urządzeń, wybiórcze wylogowywanie użytkowników po wykryciu nieprawidłowości itp itd), więc po co dodatkowo dorabiać akrobacje z JWT na frontendzie? Przesyłajmy tylko kompaktowe ID sesji w ciastku, a po stronie serwera wstawmy w Redisie słownik z ID sesji jako kluczem i metadanymi jako wartością. Nikt nie udowodnił, że żonglowanie JWT na frontendzie jest bezpieczniejsze od starych sprawdzonych ciastek z IDkami sesji. Z drugiej strony wymyślanie mechanizmu bezpieczeństwa samemu jest bardziej narażone na błędy niż użycie sprawdzonego gotowca opartego o klasyczne ciasteczka z IDkami sesji. JWT są natomiast spoko gdy są jednorazowego użytku (a tak są używane np na backendzie).

1 użytkowników online, w tym zalogowanych: 0, gości: 1