JWT (JSON Web Token) automatyczne przedłużanie ważności

509

Chciałbym zaimplementować uwierzytelnianie oparte na JWT w naszym nowym interfejsie API REST. Ale skoro wygaśnięcie jest ustawione w tokenie, czy można go automatycznie przedłużyć? Nie chcę, aby użytkownicy musieli logować się co X minut, jeśli w tym okresie aktywnie korzystali z aplikacji. To byłaby ogromna awaria UX.

Ale przedłużenie ważności powoduje utworzenie nowego tokena (i stary jest nadal ważny, aż do wygaśnięcia). A generowanie nowego tokena po każdym żądaniu wydaje mi się głupie. Brzmi jak problem z bezpieczeństwem, gdy więcej niż jeden token jest ważny jednocześnie. Oczywiście mógłbym unieważnić stary używany przy użyciu czarnej listy, ale musiałbym przechowywać tokeny. Jedną z zalet JWT jest brak pamięci.

Odkryłem, jak Auth0 to rozwiązało. Używają nie tylko tokenu JWT, ale także tokenu odświeżania: https://docs.auth0.com/refresh-token

Ale ponownie, aby to zaimplementować (bez Auth0) musiałbym przechowywać tokeny odświeżania i zachować ich wygaśnięcie. Jaka jest zatem prawdziwa korzyść? Dlaczego nie mieć tylko jednego tokena (nie JWT) i zachować datę ważności na serwerze?

Czy są inne opcje? Czy użycie JWT nie jest odpowiednie dla tego scenariusza?

maryo
źródło
1
W rzeczywistości prawdopodobnie nie ma problemu z bezpieczeństwem wielu prawidłowych tokenów na raz ... W rzeczywistości istnieje nieskończona liczba prawidłowych tokenów ... Więc po co więc mieć token odświeżania? Ponownie je wygeneruję po każdym żądaniu, w rzeczywistości nie powinno to stanowić problemu.
maryo
1
W przypadku SPA sprawdź
wong2
2
@maryo Wydaje mi się, że posiadanie (potencjalnie) setek lub tysięcy nieużywanych ważnych JWT w dowolnym momencie zwiększa zasięg ataku i stanowi zagrożenie bezpieczeństwa. Moim zdaniem JWT powinny być wydawane ostrożnie, ponieważ w pewien sposób są to tokeny dostępu z kluczami do zamku.
java-addict301

Odpowiedzi:

589

Pracuję w Auth0 i byłem zaangażowany w projektowanie funkcji tokena odświeżania.

Wszystko zależy od rodzaju aplikacji i oto nasze zalecane podejście.

Aplikacje internetowe

Dobrym przykładem jest odświeżenie tokena przed jego wygaśnięciem.

Ustaw datę ważności tokena na jeden tydzień i odświeżaj token za każdym razem, gdy użytkownik otwiera aplikację internetową i co godzinę. Jeśli użytkownik nie otworzy aplikacji przez ponad tydzień, będzie musiał się ponownie zalogować, a to jest akceptowalna aplikacja internetowa UX.

Aby odświeżyć token, interfejs API potrzebuje nowego punktu końcowego, który odbiera prawidłowy, nie wygasły JWT i zwraca ten sam podpisany JWT z nowym polem wygaśnięcia. Następnie aplikacja internetowa gdzieś zapisze token.

Aplikacje mobilne / natywne

Większość aplikacji natywnych loguje się raz i tylko raz.

Chodzi o to, że token odświeżania nigdy nie wygasa i zawsze można go wymienić na prawidłowy JWT.

Problem z tokenem, który nigdy nie wygasa, polega na tym, że nigdy nie oznacza nigdy. Co robisz, jeśli zgubisz telefon? Dlatego musi być w jakiś sposób identyfikowalny przez użytkownika, a aplikacja musi zapewniać sposób cofnięcia dostępu. Zdecydowaliśmy się użyć nazwy urządzenia, np. „IPad Maryo”. Następnie użytkownik może przejść do aplikacji i cofnąć dostęp do „iPada Maryo”.

Innym podejściem jest odwołanie tokena odświeżania dla określonych zdarzeń. Ciekawym wydarzeniem jest zmiana hasła.

Uważamy, że JWT nie jest przydatny w tych przypadkach użycia, dlatego używamy losowo generowanego ciągu i przechowujemy go po naszej stronie.

José F. Romaniello
źródło
42
W przypadku podejścia zalecanego przez aplikacje internetowe, jeśli token jest ważny przez tydzień, czy nie mamy na myśli tego, że ktoś przechwyci token i będzie mógł go używać przez tak długi czas? Uwaga: Nie do końca wiem o czym mówię.
user12121234
30
@ przechwytywanie tak jest problemem, nawet w przypadku plików cookie. Powinieneś użyć https.
José F. Romaniello
15
@ JoséF.Romaniello W twoim przykładzie aplikacji wszystko ma dla mnie sens oprócz konieczności przechowywania tokena. Myślałem, że pięknem JWT jest bezpaństwowe uwierzytelnianie - co oznacza, że ​​aplikacja internetowa NIE musi przechowywać tokena, ponieważ jest podpisany. Wydaje mi się, że serwer może po prostu sprawdzić ważność tokena, upewnić się, że jest w okresie wygaśnięcia, a następnie wydać odnowiony token JWT. Czy mógłbyś rozwinąć tę kwestię? Może po prostu jeszcze nie rozumiem wystarczająco dużo JWT.
Lo-Tan,
7
Dwa pytania / wątpliwości: 1- Przypadek aplikacji sieci Web: dlaczego nie można pozwolić, aby token, który wygasł, mógł uzyskać odświeżenie? Załóżmy, że ustawiliśmy krótki okres ważności (1 godzina) i wykonamy odnowione połączenia z serwerem zaplecza, gdy wygaśnie token, jak powiedziałeś. 2- Czy istnieje problem bezpieczeństwa związany z przechowywaniem zaszyfrowanego (losowego hasła) hasła w tokenie? Chodzi o to, że jeśli tam jest, serwer zaplecza może sprawdzić zapisane hasło w bazie danych, gdy zostanie poproszony o odnowienie, i odrzucić żądanie, jeśli hasła się nie zgadzają. Obejmowałoby to zmianę hasła aplikacji mobilnej / natywnej, umożliwiając rozszerzenie rozwiązania na przypadek użycia mobilnego.
psamaan
7
-1 Ujawnienie publicznego interfejsu API, który ślepo ponownie podpisuje dowolny token, aby przedłużyć jego okres sprawdzania poprawności, jest złe. Teraz wszystkie twoje tokeny wygasają bez końca. Akt podpisania tokena powinien obejmować odpowiednie kontrole uwierzytelnienia dla każdego roszczenia zgłoszonego na tym tokenie w momencie podpisywania.
Phil
69

W przypadku samodzielnej obsługi autoryzacji (tzn. Nie korzystania z dostawcy takiego jak Auth0) mogą działać następujące czynności:

  1. Wydaj token JWT z relatywnie krótkim okresem ważności, powiedzmy 15min.
  2. Aplikacja sprawdza datę ważności tokena przed każdą transakcją wymagającą tokena (token zawiera datę ważności). Jeśli token wygasł, najpierw prosi API o „odświeżenie” tokena (odbywa się to w sposób transparentny dla UX).
  3. Interfejs API otrzymuje żądanie odświeżenia tokena, ale najpierw sprawdza bazę danych użytkowników, aby sprawdzić, czy flaga „reauth” została ustawiona dla tego profilu użytkownika (token może zawierać identyfikator użytkownika). Jeśli flaga jest obecna, to odświeżanie tokena jest odrzucane, w przeciwnym razie wydawany jest nowy token.
  4. Powtarzać.

Flaga „reauth” w zapleczu bazy danych zostanie ustawiona, gdy na przykład użytkownik zresetuje hasło. Flaga zostanie usunięta, gdy użytkownik zaloguje się następnym razem.

Ponadto załóżmy, że masz politykę, zgodnie z którą użytkownik musi logować się co najmniej raz na 72 godziny. W takim przypadku logika odświeżania tokena API sprawdzi również datę ostatniego logowania użytkownika z bazy danych użytkownika i odmówi / zezwoli na odświeżenie tokena na tej podstawie.

IanB
źródło
7
Nie sądzę, żeby to było bezpieczne. Gdybym był atakującym i ukradłem twój token i wysłałem go na serwer, serwer sprawdzi i zobaczy flagę ustawioną na true, co jest świetne, ponieważ blokuje odświeżanie. Myślę, że problem polegałby na tym, że jeśli ofiara zmieniła hasło, flaga byłaby ustawiona na false, a teraz atakujący może użyć tego oryginalnego tokena do odświeżenia.
user2924127
6
@ user2924127 żadne rozwiązanie uwierzytelniania nie jest idealne i zawsze będą występowały kompromisy. Jeśli atakujący może „ukraść twój token”, możesz mieć większe problemy do zmartwienia. Ustawienie maksymalnego czasu życia tokena byłoby użytecznym ulepszeniem powyższego.
IanB
27
zamiast mieć inne pole w bazie danych, flagę ponownie, możesz dołączyć do tokenu hash (bcrypt_password_hash). Następnie podczas odświeżania tokena wystarczy potwierdzić, czy skrót (bcrypt_password_hash) jest równy wartości z tokena. Aby odmówić odświeżenia tokena, wystarczy zaktualizować skrót hasła.
bas
4
@bas, myśląc o optymalizacji i wydajności, myślę, że sprawdzanie poprawności skrótu hasła byłoby zbędne i miałoby więcej implikacji dla serwera. Zwiększ rozmiar tokena, aby firma podpisująca / weryfikacja zajęła więcej czasu. dodatkowe obliczenia skrótu dla serwera dla hasła. z dodatkowym podejściem do pola, które sprawdzasz podczas przeliczania za pomocą prostej wartości logicznej. Aktualizacje DB są rzadsze dla dodatkowego pola, ale częściej odświeżają token. Otrzymujesz opcjonalną usługę wymuszania indywidualnych ponownych logowania dla każdej istniejącej sesji (mobilnej, internetowej itp.).
le0diaz 14.04.16
6
Myślę, że pierwszy komentarz użytkownika2929127 jest w rzeczywistości błędny. Po zmianie hasła konto jest oznaczane jako wymagające ponownego uwierzytelnienia, więc wszelkie istniejące tokeny, które wygasły, będą nieważne.
Ralph
15

Majstrowałem przy przenoszeniu naszych aplikacji do HTML5 z RESTful apis w backend. Rozwiązaniem, które wymyśliłem, było:

  1. Klient otrzymuje token z czasem sesji wynoszącym 30 minut (lub innym zwykłym czasem sesji po stronie serwera) po pomyślnym zalogowaniu.
  2. Licznik czasu po stronie klienta jest tworzony w celu wezwania usługi w celu odnowienia tokena przed jego upływem. Nowy token zastąpi istniejące w przyszłych połączeniach.

Jak widać, zmniejsza to częste żądania tokenów odświeżania. Jeśli użytkownik zamknie przeglądarkę / aplikację przed wyzwoleniem wywołania odnowienia tokena, poprzedni token wygaśnie z czasem i użytkownik będzie musiał się ponownie zalogować.

Bardziej skomplikowaną strategię można wdrożyć, aby zaspokoić brak aktywności użytkowników (np. Zaniedbano otwartą kartę przeglądarki). W takim przypadku odnowienie wywołania tokena powinno obejmować przewidywany czas wygaśnięcia, który nie powinien przekraczać zdefiniowanego czasu sesji. Aplikacja będzie musiała odpowiednio śledzić ostatnią interakcję użytkownika.

Nie podoba mi się pomysł ustawiania długiego okresu ważności, dlatego takie podejście może nie działać dobrze w przypadku aplikacji natywnych wymagających rzadszego uwierzytelniania.

Coolersport
źródło
1
Co jeśli komputer został zawieszony / uśpiony. Minutnik nadal będzie się liczył, aż do wygaśnięcia, ale token faktycznie wygasł. Timer nie działa w takich sytuacjach
Alex Parij
@AlexParij Porównałbyś z ustalonym czasem, coś takiego: stackoverflow.com/a/35182296/1038456
Aparajita
2
Umożliwienie klientowi żądania nowego tokena z preferowaną datą ważności pachnie dla mnie zagrożeniem bezpieczeństwa.
java-addict301
14

Alternatywnym rozwiązaniem dla unieważniania JWT, bez dodatkowego bezpiecznego przechowywania w backendie, jest zaimplementowanie nowej jwt_versionkolumny liczb całkowitych w tabeli użytkowników. Jeśli użytkownik chce się wylogować lub wygasnąć istniejące tokeny, po prostu zwiększa jwt_versionpole.

Podczas generowania nowego JWT zakoduj go jwt_versiondo ładunku JWT, opcjonalnie zwiększając wcześniej wartość, jeśli nowy JWT powinien zastąpić wszystkie inne.

Podczas sprawdzania poprawności JWT jwt_versionpole jest porównywane obok, user_ida autoryzacja jest udzielana tylko wtedy, gdy jest zgodna.

Ollie Bennett
źródło
1
Ma to problemy z wieloma urządzeniami. Zasadniczo, jeśli wylogujesz się na jednym urządzeniu, wyloguje się ono wszędzie. Dobrze?
Sam Washburn
4
Hej, to może nie być „problem” w zależności od twoich wymagań, ale masz rację; nie obsługuje to zarządzania sesjami na urządzeniu.
Ollie Bennett
Czy to nie oznacza, że ​​jwt_version musi być przechowywany po stronie serwera, aby schemat uwierzytelniania stał się „podobny do sesji” i pokonał podstawowy cel JWT?
ChetPrickles
8

Dobre pytanie - w samym pytaniu jest mnóstwo informacji.

Artykuł Odśwież tokeny: kiedy ich używać i jak wchodzą w interakcje z JWT daje dobry pomysł na ten scenariusz. Niektóre punkty to: -

  • Tokeny odświeżające zawierają informacje niezbędne do uzyskania nowego tokena dostępu.
  • Tokeny odświeżania mogą również wygasać, ale są raczej długotrwałe.
  • Tokeny odświeżające zwykle podlegają ścisłym wymaganiom dotyczącym przechowywania, aby zapewnić, że nie wyciekną.
  • Mogą być również umieszczeni na czarnej liście przez serwer autoryzacji.

Zobacz także auth0 / angular-jwt angularjs

W przypadku interfejsu API sieci Web. czytaj Włącz tokeny odświeżania OAuth w aplikacji AngularJS przy użyciu ASP .NET Web API 2 i Owin

LCJ
źródło
Może źle to odczytałem ... Ale artykuł z tytułem, który zaczyna się jako „Odśwież tokeny ...”, nie zawiera niczego na temat tokenów odświeżania, oprócz tego, o czym tu wspomniałeś.
Ievgen Martynov
8

Zaimplementowałem to w PHP za pomocą klienta Guzzle do stworzenia biblioteki klienta dla interfejsu API, ale koncepcja powinna działać na innych platformach.

Zasadniczo emituję dwa tokeny, krótki (5 minut) i długi, który wygasa po tygodniu. Biblioteka klienta używa oprogramowania pośredniego do próby odświeżenia krótkiego tokena, jeśli otrzyma odpowiedź 401 na niektóre żądanie. Następnie spróbuje ponownie wykonać oryginalne żądanie i jeśli będzie w stanie odświeżyć, otrzyma prawidłową odpowiedź, w sposób przezroczysty dla użytkownika. Jeśli się nie powiedzie, po prostu wyśle ​​401 do użytkownika.

Jeśli wygasł krótki token, ale nadal jest autentyczny, a długi token jest ważny i autentyczny, odświeży krótki token za pomocą specjalnego punktu końcowego w usłudze, który uwierzytelnia długi token (jest to jedyna rzecz, do której można go użyć). Następnie użyje krótkiego tokena, aby uzyskać nowy długi token, przedłużając go o kolejny tydzień za każdym razem, gdy odświeża krótki token.

Takie podejście pozwala nam również cofnąć dostęp w ciągu maksymalnie 5 minut, co jest dopuszczalne do naszego użytku bez konieczności przechowywania czarnej listy tokenów.

Późna edycja: Ponownie przeczytam te miesiące po tym, jak było świeżo w mojej głowie, powinienem zauważyć, że możesz odwołać dostęp podczas odświeżania krótkiego tokena, ponieważ daje to możliwość droższych połączeń (np. Połączenia z bazą danych, aby sprawdzić, czy użytkownik został zbanowany) bez płacenia za to przy każdym pojedynczym połączeniu z Twoją usługą.

BytePorter
źródło
8

Poniżej znajdują się kroki, aby cofnąć swój token dostępu JWT:

1) Po zalogowaniu wyślij 2 tokeny (token dostępu, token odświeżenia) w odpowiedzi na klienta.
2) Token dostępu będzie miał krótszy czas wygaśnięcia, a Odśwież będzie miał długi czas wygaśnięcia.
3) Klient (interfejs użytkownika) będzie przechowywać token odświeżania w swoim lokalnym magazynie i token dostępu w plikach cookie.
4) Klient użyje tokena dostępu do wywoływania api. Ale kiedy wygaśnie, wybierz token odświeżania z pamięci lokalnej i wywołaj interfejs serwera autoryzacji, aby pobrać nowy token.
5) Na Twoim serwerze autoryzacji będzie widoczny interfejs API, który zaakceptuje token odświeżania, sprawdzi jego ważność i zwróci nowy token dostępu.
6) Po wygaśnięciu tokena odświeżania użytkownik zostanie wylogowany.

Daj mi znać, jeśli potrzebujesz więcej szczegółów, mogę również udostępnić kod (Java + Spring boot).

Bhupinder Singh
źródło
Czy możesz udostępnić link do projektu, jeśli masz go w GitHub?
Arun Kumar N
6

jwt-autorefresh

Jeśli używasz węzła (React / Redux / Universal JS), możesz zainstalować npm i -S jwt-autorefresh.

Ta biblioteka planuje odświeżanie tokenów JWT na podstawie obliczonej przez użytkownika liczby sekund przed wygaśnięciem tokena dostępu (na podstawie oświadczenia exp zakodowanego w tokenie). Posiada obszerny zestaw testów i sprawdza całkiem sporo warunków, aby upewnić się, że każdej dziwnej aktywności towarzyszy opisowy komunikat dotyczący błędnych konfiguracji z twojego środowiska.

Pełna implementacja przykładu

import autorefresh from 'jwt-autorefresh'

/** Events in your app that are triggered when your user becomes authorized or deauthorized. */
import { onAuthorize, onDeauthorize } from './events'

/** Your refresh token mechanism, returning a promise that resolves to the new access tokenFunction (library does not care about your method of persisting tokens) */
const refresh = () => {
  const init =  { method: 'POST'
                , headers: { 'Content-Type': `application/x-www-form-urlencoded` }
                , body: `refresh_token=${localStorage.refresh_token}&grant_type=refresh_token`
                }
  return fetch('/oauth/token', init)
    .then(res => res.json())
    .then(({ token_type, access_token, expires_in, refresh_token }) => {
      localStorage.access_token = access_token
      localStorage.refresh_token = refresh_token
      return access_token
    })
}

/** You supply a leadSeconds number or function that generates a number of seconds that the refresh should occur prior to the access token expiring */
const leadSeconds = () => {
  /** Generate random additional seconds (up to 30 in this case) to append to the lead time to ensure multiple clients dont schedule simultaneous refresh */
  const jitter = Math.floor(Math.random() * 30)

  /** Schedule autorefresh to occur 60 to 90 seconds prior to token expiration */
  return 60 + jitter
}

let start = autorefresh({ refresh, leadSeconds })
let cancel = () => {}
onAuthorize(access_token => {
  cancel()
  cancel = start(access_token)
})

onDeauthorize(() => cancel())

Uwaga: Jestem opiekunem

cchamberlain
źródło
Pytanie o to, widziałem używaną funkcję dekodowania. Czy zakłada, że ​​JWT można zdekodować bez użycia tajemnicy? Czy to działa z JWT, które zostały podpisane tajemnicą?
Gian Franco Zabarino
3
Tak, dekodowanie jest dekodowaniem tylko dla klienta i nie powinno być świadome tajemnicy. Sekret służy do podpisywania tokenu JWT po stronie serwera w celu sprawdzenia, czy podpis został pierwotnie użyty do wygenerowania JWT i nigdy nie powinien być używany przez klienta. Magią JWT jest to, że jego ładunek może być odkodowany po stronie klienta, a oświadczenia w nim zawarte mogą zostać użyte do zbudowania interfejsu użytkownika bez tajemnicy. Jedyną rzeczą, która jwt-autorefreshgo dekoduje, jest wyodrębnienie exproszczenia, aby mógł określić, jak daleko jest do zaplanowania następnego odświeżenia.
cchamberlain
1
Och, dobrze wiedzieć, coś nie miało sensu, ale teraz ma. Dziękuję za odpowiedź.
Gian Franco Zabarino
4

Rozwiązałem ten problem, dodając zmienną do danych tokena:

softexp - I set this to 5 mins (300 seconds)

Ustawiam expiresInopcję na żądany czas, zanim użytkownik będzie zmuszony ponownie się zalogować. Mój ustawiony jest na 30 minut. To musi być większa niż wartośćsoftexp .

Gdy moja aplikacja po stronie klienta wysyła żądanie do interfejsu API serwera (gdzie wymagany jest token, np. Strona listy klientów), serwer sprawdza, czy przesłany token jest nadal ważny, czy nie, w oparciu o jego pierwotną expiresInwartość expiration ( ). Jeśli to nie jest poprawne, serwer zareaguje ze statusem szczególnym dla tego błędu, np.INVALID_TOKEN.

Jeśli token jest nadal ważny na podstawie expiredInwartości, ale już przekroczył softexpwartość, serwer odpowie osobnym statusem dla tego błędu, np. EXPIRED_TOKEN:

(Math.floor(Date.now() / 1000) > decoded.softexp)

Po stronie klienta, jeśli otrzymał EXPIRED_TOKEN odpowiedź, powinien odnowić token automatycznie, wysyłając żądanie odnowienia do serwera. Jest to przezroczyste dla użytkownika i automatycznie obsługiwane przez aplikację kliencką.

Metoda odnowienia na serwerze musi sprawdzić, czy token jest nadal ważny:

jwt.verify(token, secret, (err, decoded) => {})

Serwer odmówi odnowienia tokenów, jeśli nie powiedzie się powyższa metoda.

James A.
źródło
Ta strategia wygląda dobrze. Ale myślę, że powinien być uzupełniony rodzajem „maksymalnej ilości odnowień”, ponieważ (być może) sesja użytkownika może żyć wiecznie.
Juan Ignacio Barisich
1
Możesz ustawić zmienną hardExp w danych tokena, aby ustawić maksymalną datę wymuszenia wygaśnięcia tokena, lub może licznik, który jest zmniejszany za każdym razem, gdy token jest odnawiany, ograniczając całkowitą liczbę odnawianych tokenów.
James A
1
To jest poprawne. Uważam to za „obowiązkowe”.
Juan Ignacio Barisich
2

Co powiesz na to podejście:

  • Dla każdego żądania klienta serwer porównuje czas wygaśnięcia tokena z (currentTime - lastAccessTime)
  • Jeśli expirationTime <(currentTime - lastAccessedTime) , zmienia ostatni lastAccessedTime na currentTime.
  • W przypadku braku aktywności w przeglądarce na czas przekraczający czas wygaśnięcia lub w przypadku, gdy okno przeglądarki zostało zamknięte, a czas wygaśnięcia> (currentTime - lastAccessedTime) , a następnie serwer może wygasnąć token i poprosić użytkownika o ponowne zalogowanie.

W tym przypadku nie wymagamy dodatkowego punktu końcowego do odświeżenia tokena. Byłby wdzięczny za każdy feedack.

sjaiswal
źródło
Czy to dobry wybór w dzisiejszych czasach, wygląda na to, że jest dość łatwy do wdrożenia.
b.ben
4
W takim przypadku, gdzie przechowujesz lastAccessedTime? Musisz to zrobić na zapleczu i na żądanie, aby stało się niepożądanym stanowym rozwiązaniem.
antgar9
2

Obecnie wiele osób decyduje się na zarządzanie sesjami za pomocą JWT, nie zdając sobie sprawy z tego, co rezygnują ze względu na postrzeganą prostotę. Moja odpowiedź dotyczy drugiej części pytań:

Jaka jest zatem prawdziwa korzyść? Dlaczego nie mieć tylko jednego tokena (nie JWT) i zachować datę ważności na serwerze?

Czy są inne opcje? Czy użycie JWT nie jest odpowiednie dla tego scenariusza?

JWT są w stanie obsługiwać podstawowe zarządzanie sesjami z pewnymi ograniczeniami. Będąc samoopisującymi się tokenami, nie wymagają one żadnego stanu po stronie serwera. To sprawia, że ​​są atrakcyjne. Na przykład, jeśli usługa nie ma warstwy trwałości, nie musi jej wnosić tylko do zarządzania sesjami.

Jednak bezpaństwowość jest również główną przyczyną ich wad. Ponieważ są wydawane tylko raz ze stałą zawartością i wygaśnięciem, nie można robić rzeczy, które chciałbyś zrobić przy typowej konfiguracji zarządzania sesją.

Mianowicie nie można unieważnić ich na żądanie. Oznacza to, że nie można wdrożyć bezpiecznego wylogowania, ponieważ nie ma możliwości wygaśnięcia już wydanych tokenów. Nie można również wprowadzić limitu czasu bezczynności z tego samego powodu. Jednym z rozwiązań jest utrzymanie czarnej listy, ale wprowadza ona stan.

Napisałem post wyjaśniający te wady bardziej szczegółowo. Aby to wyjaśnić, możesz obejść je, dodając więcej złożoności (sesje przesuwane, tokeny odświeżania itp.)

Jeśli chodzi o inne opcje, jeśli Twoi klienci wchodzą w interakcje z Twoją usługą tylko za pośrednictwem przeglądarki, zdecydowanie zalecamy korzystanie z rozwiązania do zarządzania sesjami opartego na plikach cookie. Opracowałem także metody uwierzytelniania list, które są obecnie szeroko stosowane w Internecie.

Daniel Szpisjak
źródło