Cześć. Nie wiem czy to jest dobre miejsce na takie pytanie ale robię to w springu więc, piszę tutaj. Ostatnio uczyłem się i zaimplementowałem jwt z użyciem refresh tokenów. Wszystko fajnie, refresh tokeny trzymam w bazie danych jako UUID, po stronie klienta trzymam w ciasteczku httpOnly i sameSite a jwt w pamięci. Tylko teraz mnie naszła taka rzecz. Czy to JWT jest mi do czegoś potrzebne? Nie mógłbym w sumie bazować na samym refresh tokenie i przy każdym zapytaniu do serwera pobierać na jego podstawie dane o userze z bazy i dawać mu dostęp na podstawie tych danych lub nie a po stronie klienta trzymać tak jak pisałem w ciasteczku httpOnly i sameSite? Nie było by lepiej i łatwiej? Pojawia się dodatkowe zapytanie do bazy zawsze jedynie.
Spring 
- Rejestracja:około 20 lat
- Ostatnio:około 10 godzin
1
JWT na frontendzie to hipsterska moda. Skoro i tak są stanowe (bo te do zewnętrznego użycia muszą być) to czemu nie użyć zwykłych ciastek z ID sesji? Nie musisz trzymać metadanych o zalogowanych użytkownikach w bazie SQLowej, możesz trzymać w Redisie (czy innym key-value store), który jest znacznie szybszy niż SELECTy z typowych baz danych.
edytowany 2x, ostatnio: Wibowit
- Rejestracja:prawie 7 lat
- Ostatnio:ponad rok
- Lokalizacja:Wrocław
- Postów:159
- Rejestracja:około 9 lat
- Ostatnio:około godziny
- Postów:5146
0
np. do cross app/server auth
edytowany 1x, ostatnio: WeiXiao
Zobacz pozostałe 27 komentarzy
ktoś może sobie wrzucać tam losowe guidy i aż trafi usera - ktoś może też wrzucać jednego i tego samego JWT z różnymi podpisami, aż trafi - przy odpowiednio dobranych rozmiarach guidów i podpisów to będzie tak samo prawdopodobne. długość życia - nie, bo to jest bardzo ograniczone. Co jeśli usunę konto albo zechcę się wylogować z poziomu fb z apek na których jestem zalogowany? w sumie nie wiem czy fb to umożliwia, ale teoretycznie jest to możliwe. Na pewno gmail umożliwia wylogowanie się z innych urządzeń / sesji. Wielorazowego użytku JWT mają podobne problemy wszędzie.
ktoś może też wrzucać jednego i tego samego JWT z różnymi podpisami, aż trafi co masz na myśli? Wielorazowego użytku JWT mają podobne problemy wszędzie. można blacklistować.
co masz na myśli? - mam na myśli to, że JWT jest zabezpieczony przez szyfrowanie albo podpisywanie i tutaj też można to zbrute'ować tak samo "szybko" jak można zbrute'ować równie długiego GUIDa można blacklistować - blacklista to stan po stronie serwera, więc skoro już go mamy to dlaczego nie przenieść do niego wszystkich danych z JWT i tym samym odchudzić przesyłane dane? w ogóle stan po stronie serwera to dużo bardziej elastyczne rozwiązanie niż próby zarządzania świeżością i poprawnością danych w JWT.
Ok,
fb.com odda Ci do serwera guida, i skąd Ty będziesz wiedział co on reprezentuje? jeżeli będzie to id usera, to będzie on zawsze taki sam, czyli słabo. Stosując jwt dostajesz jsona wypełnionego danymi.
Zauważ, że w schemacie na obrazku który podałeś aplikacja robi 2 żądania do fb.com. Jedno (GET /oauth/authorize) jest o zwykły token (czyli GUID), a drugie (GET /me?access_token=... wykorzystujące ten token) jest o dane użytkownika. Mając GUIDa mogę co 5 minut pytać o świeże dane na temat użytkownika, a w drugą stronę fb nie musi sprawdzać świeżości i poprawności danych z tokena bo ich tam nie ma.
Zarejestruj się i dołącz do największej społeczności programistów w Polsce.
Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.
Ja nie mowie w ogole o sesji- no to o czym? Ja twierdzę, że na frontendzie lepsze są ciastka z ID sesji, a na backendzie jednorazowe JWT są OK. Do czego się odnosisz?