2015-07-30 27 views
9

Przeglądałem pytania, ale nie znalazłem niczego, co mogłoby rozwiać moje wątpliwości. Znalazłem obszerne informacje na temat JWT, ale niewiele, gdy porównywałem zalety, jakie JWT mogłaby zaoferować, generując niestandardowy token do żądań uwierzytelnienia wobec usług REST.JWT (Json web token) Vs Custom Token

Jaka jest korzyść z używania JWT (Json Web Token) do generowania niestandardowego tokena generującego? Do wygenerowania tokena niestandardowego mogłem użyć strategii mieszania lub jakiegoś unikalnego generatora liczb losowych.

Jeśli wygeneruję niestandardowy token, czy mogę mieć jakiekolwiek obawy dotyczące bezpieczeństwa? Czy poleciłbyś skorzystać z innych metod uwierzytelniania?

Dzięki!

+0

Cześć Deibys, mam to samo pytanie, czy znalazłeś jakąś przekonującą odpowiedź i jakie podejście w końcu zastosowałeś? dzięki –

Odpowiedz

8

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.

+3

Sam JWT nie zapewnia żadnych środków przeciwko CSRF ani atakom XSS. Podpisywanie jest środkiem zapobiegającym naruszeniu tokena. Token może zostać skradziony, nawet jeśli jest podpisany. Stormpath ma dobry artykuł opisujący, gdzie należy przechowywać tokeny JWT i jak chronić się przed CSFR i XSS. https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/ –

+4

Samo tokenów JWT nie chroni przed CSRF, ale są one zwykle używane na okaziciela schemat uwierzytelniania. Schemat uwierzytelniania okaziciela nie jest podatny na CSRF. Przeczytałem artykuł Stormpath, ale nie zgadzam się z ich zaleceniami.Przechowywanie tokenów JWT w pliku cookie utrudnia klientom niebędącym przeglądarkami korzystanie z interfejsu API i utrudnia korzystanie z interfejsów API w różnych domenach. – MvdD

+0

Jeśli chcę, aby aplikacja była niezależna od kanału, myślę, że używanie plików cookie nie jest mądrą decyzją, słyszałem, że niektóre urządzenia przenośne mają problemy z plikami cookie. W zależności od aplikacji klienckiej, zdecydują, w jaki sposób przechowywać token (dla aplikacji przeglądarki, domyślam się, że opcja przechowywania sesji w html5 jest opcją). Teraz muszę unieważnić tokeny na każdą potrzebę, więc od strony serwera będę potrzebował dla nich pewnego magazynu danych. Czy uważasz, że można zapisać je w bazie danych? – Deibys

1

Od Django REST framework documentation,

JSON sieci Token jest to dość nowy standard, który może być używany do uwierzytelniania tokenów. W przeciwieństwie do wbudowanego schematu TokenAuthentication, uwierzytelnianie JWT nie musi używać bazy danych do sprawdzania poprawności tokena.