JWT tokens zawierają oświadczenia, które są oświadczeniami dotyczącymi tematu (na przykład zalogowanego użytkownika). Te stwierdzenia mogą być takie jak imię, e-mail, role itp. Tokeny JWT są podpisane cyfrowo i nie są podatne na ataki typu CSRF.
Te dwie cechy sprawiają, że usługa odbierająca token nie musi wracać do serwera potwierdzania autentyczności, aby zweryfikować ważność tokenu lub uzyskać informacje na jego temat.
Zwiększa to zdolność systemu wykorzystującego tokeny JWT do skalowania w znaczący sposób. Żetony JWT wymagają bezpiecznego kanału transportowego (HTTPS).
Wadą tego jest to, że tokeny nie mogą zostać odwołane (ponieważ nie ma centralnego serwera chroniącego te tokeny). To dlatego żetony mają zazwyczaj krótki czas życia.
Z drugiej strony, żetony posiadające session id muszą skontaktować się z serwerem uwierzytelniającym w celu sprawdzenia tokena (zazwyczaj przeszukiwania bazy danych) i pobrania informacji na ten temat (innego wyszukiwania bazy danych).
Walidacja numeru HMAC tokens wymaga znajomości tajnego klucza użytego do wygenerowania tokena. Zazwyczaj usługa odbierająca (Twój interfejs API) będzie musiała skontaktować się z serwerem uwierzytelniającym, ponieważ ten serwer jest tam, gdzie przechowywany jest klucz tajny.
Żetony HMAC i identyfikatory sesji są zwykle przechowywane w plikach cookie. Pliki cookie nie mogą być używane do wywoływania międzydomenowych usług i muszą być chronione przed atakami CSRF.
Cześć Deibys, mam to samo pytanie, czy znalazłeś jakąś przekonującą odpowiedź i jakie podejście w końcu zastosowałeś? dzięki –