@SendMeAnAngel: kwestia tego na jakim poziomie jest wymagane security w twoim projekcie, jesli nie robisz np aplikacji bankowej to nie powinienes sie tym przejmowac, ciezar lezy po stronie uzytkownika w przeciwnym wypadku zajmie sie tym BE, walidujac token z fingerprintem/ip/hwid usera opcji jest wiele lacznie z regeneracja tokenu czy krotka sesja (wygoda uzytkownika w przypadku duzego bezpieczenstwa nie jest priorytetem)

@SendMeAnAngel: po to JWT się stosuje, żeby było prosto, nie bezpiecznie. Jak user nie potrafi przypilnować ciastek, to już jego problem

Póki co,

@chlodna_kalkulacja: I po co ten rusycyzm? ;>

@elf_pszeniczny: dobrze ze nie L4

@TomAtari: Faktycznie, dopiero doczytałem. W sumie żadna różnica. Jeśli potrzebujesz żeby Twój JS miał dostęp do JWT to trzymasz go w localstorage, ale wtedy może go odczytać także XSS. Ciasteczka są o tyle lepsze, że możesz ustawić HTTPOnly i zabezpieczyć się przed XSSami. Requesty to prawda są podpisane, ale możesz ustawić SameSite na ciasteczku albo zaimplementować inną ochronę przed CSRF i będziesz miał podpisane tylko te requesty, których się spodziewasz.

@TomAtari: nie jestem frontem ale fronty mi opowiadają o localstorage. Ciastko odpowiada klasycznym stronom, które tworzą ciastko sesyjne. XSS powinieneś ty wycinać i backend. A jeżeli ktoś ma shackowaną przeglądarkę to i tak nic nie zrobisz.

@gajowy_marucha: Chodzi o to żeby sam token się autoryzował bez uderzania do głównej bazy (serwera autoryzującego), a jednocześnie użytkownik miał możliwość wycofania tych zezwoleń. Wycofanie nastąpi poprzez zablokowanie odświeżania (plus jakieś tymczasowe listy, powiadomienia... zależy co potrzebne i gdzie wycofano).
Sytuacja podobna do posługiwania się jakimś dokumentem, którego posiadanie uprawnia do czegoś bez konsultacji z instytucją która go wydała.