[PseudoProgramista]

Siema,

Mamy JWT, przeczytałem pół internetu i zawsze coś jest źle wg założeń i tego jak co przechowywać. Wiec przychodze jak zawsze do społeczności #programista15k

Mamy JWT, serwer je wysyła do użytkownika. Jak najlepiej ?
Cookie httponly strict secure
Header authorization Bearer

Jeśli header to gdzie przechowywać po stronie użytkownika aby używać i aby użytkownik nie był wylogowywany przy refreshach itp?

Jeśli cookie to jak odesłać do serwera w headerze ? Nie da się bo HTTP only?

Refresh token, przechowujemy gdzie ? Redis/Baza danych? Czy cookie ? Storage?

Jak upewniamy się ze nie został ukradziony ? Przypisujemy do user agenta i IP użytkownika ? A co przy zmianie IP spowodowanej resetem modemu utrata prądu itp itd czy z samoczynna zmiana która następuje po x dniach lub godzinach. Czy może po dekodowaniu jwt jeśli czas się skończył a id użytkownika z zdekodowanego jwt zgadza się z id refresh to przydzielamy nowy acces token nie zastanawiając się czy oba nie zostały po prostu wykradzione ? I wtedy w storage przechowujemy access token a refresh w HTTP only ?

I co z tym authorization headerem tak ogólnie. Widzę zadania nieraz rekrutacyjne gdzie pisze żeby tak wysyłać na frontend, i spoko. Może nie mój problem już ale ciekaw jestem jak potem jest on przechowywany na froncie ? I jak odsyłany do serwera tzn z jakiego miejsca.

Jak mamy formularz który wykonuje post na dany endpoint to jak dodajemy authorization Bearer do formularza ? Czy do każdego formularza należy pisać js i nie korzystać z „automatycznego” wysyłania ?

#programowanie #nodejs #expressjs

[LazyInitializationException]

@PseudoProgramista: Problem jest w tym, że ty po prostu nie wiesz jak to powinno działać.

Mamy JWT, serwer je wysyła do użytkownika. Jak najlepiej ?

Cookie httponly strict secure

Header authorization Bearer

Ani tak ani tak. A header authorization to się używa do autoryzacji a nie do zwracania danych z serwera.

User wysyła na serwer login i hasło a w odpowiedzi w body dostaje access token. Żeby było prawilnie to powinien

[Makurise]

@LazyInitializationException:

W local storage trzymasz refresh token

Ale weź nie trolluj, bo chłop serio kiedyś wrzuci token w local storage xD Wrażliwe dane zawsze jako cookie z flagą HttpOnly i określonym Expires

[LazyInitializationException]

@Makurise: ok z tym racja

[PseudoProgramista]

@LazyInitializationException: chcesz wiedzieć jak to powinno działać ? Tak ze token jest tylko w lokalnej zmiennej zapisaniu po stronie frontu i wysyłany w headerze. Od backendu do frontendu I tak zaczniesz się śmiać, ale stety niestety tak powinno używać się Bearer tokenów. I nie ma czegoś takiego jak refresh token bo nie zgadza się z z pierwotnym założeniem JWT.

Refresh token w localStorage ? Heh ok
Acces token to przepada jak

[PseudoProgramista]

@Makurise: mamy 2021, httponly i SameSite: strict i secure jak już chcesz pokazać jaki obrotny jesteś.

[PseudoProgramista]

@LazyInitializationException: jutro Ci podlinkuje dokumentacje związana z tym standardem zabezpieczenia plus kilka dokładniejszych odpowiedzi na stackoverflow. Bo tak jak Ty napisałeś to spoko zrozumiałe, tylko tak nie wyglada prawidłowa implementacja

[LazyInitializationException]

Bo tak jak Ty napisałeś to spoko zrozumiałe, tylko tak nie wyglada prawidłowa implementacja

@PseudoProgramista: no to podeślij. Ciekawy jestem co podeślesz skoro JWT to jest tylko standard tworzenia tokena i podpisywania go, a tego tematu w ogóle nie poruszyliśmy xD

nie ma czegoś takiego jak refresh token bo nie zgadza się z z pierwotnym założeniem JWT.

JWT w ogóle nie definiuje takiego pojęcia jak access token czy refresh token, więc

[4191727801]

@LazyInitializationException: @Makurise a jaka jest roznica czy wrzuci jwt w cookies czy local storage? Jesli ktos uzyska dostep do twojej przegladarki to i stad i stamtąd wyciagnie token.

OP pytal o skradziony token: wg mnie chcial zapytac o blackliste i sposoby na wylogowanie usera "przez serwer".
Przyklad: user stracil dostep do platnej uslugi bo nie zaplacil abonamentu. Gdyby ciągle generowal refresh token i nie byloby mechanizmu blacklisty, to nigdy nie stracilby

[Makurise]

@4191727801: Do local storage i zwykłych cookies masz dostęp z poziomu JS - flagą HttpOnly blokujesz ten dostęp. Wtedy ten ktoś musi mieć fizyczny dostęp do twojej przeglądarki. Tak samo local storage samo z siebie się nie czyści, co może być problematyczne przy zmianie lub utracie/kradzieży sprzętu - stąd dobrze jest ustawić w miarę krótkie Expires na cookies (przykładowo tydzień).

@PseudoProgramista: No i już widzę, że nic nie wiesz i

[Makurise]

@PseudoProgramista: Zresztą masz internet, masz przeglądarkę, możesz sobie sam sprawdzić jak są ustawiane ciasteczka z tokenami na różnych stronach - tych większych, mniejszych, bardziej security-oriented czy mniej, etc. W 99% przypadków jeżeli będzie flaga Secure, to SameSite będzie wynosiło None (czyli Secure włączone z powodu cross-site). Samych SameSite: Strict to na palcach jednej ręki policzysz po przejrzeniu kilku/kilkunastu stron. A połączeń (Secure i SameSite: Strict razem w ciasteczku) to prawdopodobnie w

[4191727801]

@Makurise: co do czyszczenia local storage to nie musisz tego robic. token jwt powinien miec zdefiniowane w payloadzie exp i to zalatwia sprawe. co do czytania local storage przez js to ok, ale cos za cos. Mozesz przechowac token i nie musisz logowac sie ponownie. Twoim sposobem po zamknieciu karty czeka cie logowanie

Czepiam sie bo napisales jakby trzymanie jwt w local storage bylo oczywistym bledem i amatorszczyzna a tak nie

[PseudoProgramista]

@Makurise: Super, tylko ja chce w skrócie dowiedzieć się jak prawidłowo używać jwt. Gdzie chować jak używać itp itd. Pierdyliard różnych artykułów, dokumentacji, wywiadów oglądałem. I jest conajmniej kilka sposobów gdzie potem na stackoverflow zawsze ktoś mówi ze jest źle. Ze tu refresh token ma być w bazie danych, tu ze w storage jak redis. Po stronie użytkownika ma być tu tam albo nie ma być go nigdzie bo jest Bearerem

[PseudoProgramista]

Jak pierwszy raz użyłem jwt to spoko. Teraz w apce chciałem zrobić to jak należy w 100%, zacząłem czytać i tak siedzę któryś dzień bo każdy inaczej sobie to wymyśla. Nawet są ludzie którzy robią jeden token podwójny w którego payloadzie jest refresh token.

[LazyInitializationException]

@4191727801: token jest na okaziciela, nie przechowuje się go w bazie danych. Refresh token można dać na blackliste, a jak ona jest zaimplementowana to zależy od stacku technologicznego w projekcie. Wiadomo że dobrze jakby to był jakiś Redis bo jest szybki i można ustawić czas wygaśnięcia rekordu na czas ważności refresh tokenu i wtedy mamy problem z głowy

[Makurise]

@4191727801: Local storage nie posiada flag czy parametrów, więc nie da się ustawić "systemowo" jego usunięcia z przeglądarki - musi to robić sama strona własnym kodem. Ogółem chyba coś ci się miesza, bo nie - zamknięcie przeglądarki nie wywala ci ciasteczek, jeżeli masz ustawione Expires na określony czas (przykładowo tydzień), i tak - trzymanie wrażliwych danych w local storage to amatorszczyzna i oczywisty błąd.

@PseudoProgramista: Tak to niestety wygląda -

[4191727801]

@LazyInitializationException: a gdzie napisalem zeby przechowac token w bazie? Pisalem tylko o local storage po stronie klienta

@Makurise 1. no nie ma autousuwania localstorage ale co z tego jesli token jest bezuzyteczny bo wygasl?
2. Pisales ze access token przepada po zamknieciu apki, czyli to co pisalem wyzej: ponowne logowanie. I to jest wlasnie ta roznica kiedy uzywasz localstorage. Nie zrozumiales co napisalem a nie "cos mi sie miesza" i ze

[Makurise]

@4191727801:

1. Refresh token wygasa całkowicie dopiero po jakimś określonym czasie, do tego momentu można go bez problemu pobrać skryptem z local storage i przejąć kontrolę nad kontem. A trzymając go jako ciasteczko z flagą HttpOnly nie da się go pobrać poprzez JS.

2. Nie wymaga ponownego logowania, bo od tego jest refresh token, by uzyskać nowy access token. Ty serio nie wiesz o czym gadasz i mieszasz różne pojęcia/mechanizmy.

[some_ONE]

User wysyła na serwer login i hasło a w odpowiedzi w body dostaje access token. Żeby było prawilnie to powinien też dostać refresh token, który będzie uzywał do generowania nowego access tokenu zamiast znowu wysyłać hasło i login.

@LazyInitializationException: Jeśli resource server pełni też rolę authorization servera to co daje ci zwracanie refresh tokena?

token jest na okaziciela, nie przechowuje się go w bazie danych

Zgadza się, przy założeniu idealnego scenariusza,

[LazyInitializationException]

Jeśli resource server pełni też rolę authorization servera to co daje ci zwracanie refresh tokena?

@some_ONE: Nie trzeba trzymać hasła użytkownika.

to nagle się okazuje że trzeba je trzymać w bazie xD

No to blacklista