
Json Web Token
Nadszedł ten moment w projekcie Let’s Write! kiedy dodawanie po stronie widoku mocków dla operacji bazodanowych stało się bardziej czasochłonne niż dodawanie nowych funkcjonalności. Z tego powodu zmieniłem nieco plany i już teraz zaczynam zajmować się warstwą serwerową. Pierwsze co postanowiłem obsłużyć to logowanie i rejestrowanie użytkownika. Żeby móc zapewnić bezpieczną i szybko autoryzację będę korzystał z Json Web Token. Implementacja pojawi się niedługo. W tym wpisie powiem tylko pokrótce co to jest.
Json Web Token (JWT) to rodzaj tokenu przechowywanego po stronie klienta. Jest on oparty na formacie JSON, jak z resztą wskazuje jego nazwa. Token jest zaszyfrowany po stronie serwera i tylko serwer ma klucz pozwalający zweryfikować autentyczność tokenu.
JWT składa się z trzech części. Wszystkie dane w tokenie są przepuszczone przez algorytm Base64 i dopiero w takiej postaci przechowywane.
Header
Informacja o algorytmie szyfrujących wykorzystanym przy generowaniu tokenu.
Payload
Dane, które chcemy przechowywać po stronie klienta. Nie są one zaszyfrowane. Zwykle przechowuje się tutaj dane o użytkowniku takie jak Id czy jego uprawnienia. Dzięki temu można w łatwy sposób mieć dostęp do najczęściej używanych danych po stronie klienta.
Signature
Podpis cyfrowy. Połączone w jedną całość i zaszyfrowane przez serwer header i payload. Dopiero kiedy serwer, otrzymując token razem z zapytaniem, odszyfruje tą część i porówna dane z payload przepuszcza zapytanie jako prawidłowe.
Zastosowanie Json Web Token pozwala przy okazji ograniczyć ilość zapytań do bazy. Wystarczy, że przy logowaniu pobierzemy i wyślemy do widoku takie dane jak id użytkownika, jego role, imię, nazwisko, może link do avatara i już nie musimy ich pobierać za każdym razem kiedy będziemy chcieli ich użyć, czy to po stronie widoków czy nawet po stronie serwera później. W końcu skoro podpis się zgadza to znaczy, że dane są prawidłowe i można im zaufać.
„Ograniczenie zapytań…” to chyba trochę słaby argument bo równie dobrze można trzymać dane bez zapytań do bazy po stronie serwera. Np. w zmiennych sesji. Poza tym jeśli taki token będzie np. w cookie to między serwerem a klientem te cookie będzie w kółko wędrować. No i dochodzi limit wielkości ciastka….
W takim tokenie nie trzymamy zazwyczaj tyle informacji, żeby osiągnąć limit 4kB na ciastko.
Sesja po stronie serwera staje się uciążliwa i przesadnie skomplikowana już w przypadku zastosowania load balancera kiedy każdy z serwerów musi do takiej sesji mieć dostęp. Nie mówiąc już o przypadku kiedy serwer do autoryzacji jest osobną usługą albo mamy wręcz architekturę mikroserwisów.
https://stackoverflow.com/questions/43452896/authentication-jwt-usage-vs-session/45214431#45214431