JWT, zarządzanie sesjami a konieczność potwierdzenia prawdziwości tokenu.

Question

Tokeny JWT zawierają w sobie informacje po to aby ograniczyć ilość zapytań do bazy (to je wyróżnia między innymi od sesji)

Dla bezpieczeństwa użytkowników musze zaimplementować mechanizm zarządzania sesjami z bazą danych- strona która pokazuje na jakich urządzeniach są aktywne sesje i jakie, oraz możliwość skasowania dowolnej / skasowanie wszystkich sesji po zmanie hasla prócz sesji na aktywnym urządzeniu itd.

Jeśli token będzie skasowany/dezaktywowany w bazie danych, muszę przy każdym requescie wymagającym autoryzacji sprawdzić w bazie danych czy dany token jest aktywny, aby nie dopuscic do sytuacji gdzie osoba z unieważnionym tokenem przez manager sesji ma dostęp do treści.

więc przy każdym requescie muszę robić strzał do bazy, co się mija z sensem, bo przy jednym zapytaniu, będą wykonywane 2 requesty (autoryzacyjny + docelowy (np. pobranie listy rzeczy itd.))

i bez znaczenia czy to tokeny JWT, czy sesja, i tak muszę sprawdzać czy dany token jest aktywny w bazie, zamiast bazy danych mogę przechowywać też w pamięci, ale wtedy po restarcie servera wszystkie sesje przepadną.

Czy jest jakiś sensowny sposób na to aby w zarządzaniu sesjami jakąś dezaktywować i zabronić jej dostępu w inny sposob niz sprawdzanie jej stanu dodatkowym requestem przy innym requescie?

Answer 1

Na szybko ze dwie rzeczy przychodzą mi do głowy, które pewnie można by fajnie połączyć razem:

1. Wprowadź jakiś identyfikator tokenów (globalnie unikatowy, jakiś UUID czy coś) do tego co wysyłasz w JWT. A potem lokalnie na każdym serwerze trzymaj listę unieważnionych UUIDów (cache unieważnionych tokenów). Przy restarcie serwera pobieraj listę unieważnionych UUIDów z serwera bazy danych. Do tego co jakiś czas (np. co minutę) możesz ten lokalny cache aktualizować (pull) / ew. jeśli masz możliwość, wprowadzić jakiś mechanizm typu push z bazy danych do wszystkich serwerów / ew. mix obu (best effort na push + aktualizacja co jakiś czas).
2. Wprowadź maksymalny czas życia tokenom, np. na 30 minut. Jeśli token jest starszy niż te 30 minut, to robisz request sprawdzający do bazy, i jeśli wszystko jest OK, to odnawiasz tokenowi czas życia na kolejne 30 minut. Dzięki temu wprowadzasz dość małą liczbę dodatkowych requestów kosztem 30-minutowego okna w którym token mógł zostać unieważniony, ale nadal będzie działać.

A najlepiej połącz oba - to daje stosunkowo szybki czas unieważnienia sesji (minuta lub mniej), a dodatkowo daje możliwość czyszczenia starych wpisów na liście "unieważnionych tokenów" po 30 minutach od ich wrzucenia tam (ofc można to robić np. raz dziennie, zostawiając tylko wpisy unieważnionych tokenów młodsze niż 30 minut).

Konkretne czasy podane wyżej powinieneś dostosować do obciążenia jakie przewidujesz. Np. może czas życia tokenu powinien wynosić 60 minut, a czas aktualizacji lokalnego cache (pull) 5 minut, bo masz mało replik bazy danych i dużo żądań na sekundę.

Ach, i ważne: jeśli robisz listę unieważnionych tokenów, to koniecznie wprowadź UUID; jeśli po prostu będziesz tokeny albo hashe tokenów wrzucać na listę unieważnionych to to da się obejść w JWT z uwagi na pewne detale co do tego jak base64 działa.