Gdzie trzymać JWT tokeny

Cześć,
Piszę aplikację w blazor server (dotnet 6) i zmagam się z uwierzytelnianiem użytkowników.

Obecnie mam to napisane w następujący sposób:

• Posiadam access token i refresh token, access token jest ważny 1 minutę, a refresh token jest ważny 14 dni.
• Gdy access token wygaśnie, aplikacja sprawdza, czy jest on ważny w bazie danych, a jeśli tak, odświeża go i generuje nowe tokeny.
• Oba tokeny są przechowywane w localstorage i tutaj moje pytanie, czy robię dobrze?

W blazor widziałem większość implementacji wykorzystujących localstorage, ale słyszałem różne głosy (aby trzymać je w plikach cookie lub pamięci (?)). Jaki jest najlepszy sposób, aby tokeny nie były podatne na ataki csrf, xss itp.? Powinienem trzymać oba tokeny w jednym miejscu, czy jakoś je rozdzielić?

Specjalistą nie jestem, ale...

1. Jeśli piszesz w Blazor Server to pytanie czy faktycznie potrzebujesz JWT? W końcu cały kod i tak jest wykonywany po stronie serwera.
2. Weryfikacja czy token już wygasł raczej powinna leżeć po stronie klienta. Jak serwer otrzyma JWT, który wygasł to powinna olać takiego klienta.

Odnośnie miejsca przechowywania to ja dla wersji WASM wymyśliłem coś takiego, że:
RT przechowywany jest w cookies jako HttpOnly
AT przechowywany jest w pamięci podręcznej.
W LokalStorage przechowywana jest informacja czy user jest zalogowany (czy był dla niego wygenerowany AT i jaki jest czas jego wygaśnięcia) ewentualnie inne informacje, które nie są istotne.

Strona weryfikuje czy w pamięci ma AT, jeśli nie to sprawdza LS czy user jest zalogowany. Jeśli tak, to wysyła request po nowy AT. Taka sytuacja może mieć miejsce np. gdy otworzysz drugą stronę w nowej karcie.

Możesz też szyfrować dane, które są w local storage. Kiedyś pokazywał to Carl Franklin w Blazor Train.

oba sa podatane na rozne typy atakow w teori trzymanie go w local storage umozliwa wykradniecie tokenu z poziomu javascriptu. Zalecane jest uzywanie cookiesow z flaga httpOnly

Ostatnio modne w świecie OAuth2 wydaje się podejście, że tokeny w ogóle nie są trzymane bezpośrednio po stronie przeglądarki (nawet w ciasteczku), a na specjalnie postawionym na te potrzeby backendzie - Backend For Frontend. Frontend otrzymuje wtedy standardowe ciasteczko sesyjne, a wymianą i obsługą tokenów zajmuje się backend.

Ale opcji jest kilka. W tym drafcie BCP można poczytać o różnych podejściach - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps

Akihito napisał(a):

oba sa podatane na rozne typy atakow w teori trzymanie go w local storage umozliwa wykradniecie tokenu z poziomu javascriptu. Zalecane jest uzywanie cookiesow z flaga httpOnly

Jak atakujący ma dostęp do js strony, to tak samo jak może wykraść token z localstorage, to również może wysłać żądanie z js do którego będzie dołączone ciasteczko httpOnly, różnica jest tylko taka że to pierwsze łatwiej zrobić. Czyli najlepiej wybrać rozwiązanie to które jest dla nas wygodniejsze/prostsze i ustawić bardzo restrykcyjne CSP by ograniczyć ryzyko dobrania się do js do minimum (pkt 9.9 z powyższego draftu).