JSON Web Token - dlaczego ładunek jest publiczny?

Nie rozumiem powodu, dla którego oświadczenia / ładunek JWT są publicznie widoczne po odkodowaniu go przez base64.

Czemu?

Wydaje się, że znacznie bardziej przydatne byłoby zaszyfrowanie go sekretem.

Czy ktoś może wyjaśnić, dlaczego lub w jakiej sytuacji upublicznienie tych danych jest przydatne?

pisząc JWT, prawdopodobnie masz na myśli JWS. Ponieważ JWE (który jest również „podklasą” JWT) faktycznie szyfruje jego zawartość.

— Alexey,

Odpowiedzi:

Zdecydujesz się nie szyfrować ładunku z tych samych powodów, dla których zdecydujesz się nie szyfrować niczego innego: koszt (jakkolwiek mały) przewyższa korzyść, a wiele danych po prostu nie musi być zabezpieczonych w ten sposób.

To, czego najbardziej potrzebujesz, to ochrona przed ludźmi, którzy majstrują przy danych, aby zaktualizować niewłaściwy zapis lub ktoś na koncie kontrolnym dostaje pieniądze, których nie powinien mieć. Osiąga to podpis JSON Web Token, ponieważ zmiana dowolnej części kombinacji nagłówek / ładunek / podpis unieważnia pakiet.

Pamiętaj, że nadal możesz zabezpieczyć pakiety w warstwie transportowej za pomocą protokołu SSL.

— Robert Harvey
źródło

Ach, rozumiem, więc zasadniczo JWT jest nowym tokenem CSRF. Dzięki za wyjaśnienie, to rozwiało zamieszanie.

— ineedhelp

Żaden JWT nie jest nowym tokenem CSRF. To są dwie różne rzeczy.

— Ash

@ash, jeśli szczegóły operacji są przechowywane w JWT i sprawdzone na serwerze, czy JWT nie odgrywa zasadniczo roli zapobiegania CSRF w tym scenariuszu? Rozumiem, że głównym celem waniliowego JWT jest uwierzytelnianie, co jest bardzo jasne z tej odpowiedzi. Wydaje mi się, że wyobrażałem sobie dodanie większej ilości danych i osiągnięcie dwóch rzeczy naraz.

— ineedhelp

@RobertHarvey, używasz JWT niepoprawnie. JST to termin „parasolowy” dla JWS i JWE. JWS ma się uwierzytelniać, JWE ma szyfrować. Tak więc „Celem tokenu WWW JSON jest uwierzytelnianie” powinno być w rzeczywistości „JWS ma uwierzytelniać”.

— Alexey,

@Alexey: Wprowadziłem niewielką zmianę w mojej odpowiedzi na zakwaterowanie.

— Robert Harvey

Użycie terminu podpis w RFC jest analogiczne do podpisu cyfrowego w kryptografii asymetrycznej. W kryptografii asymetrycznej, jeśli nadawca szyfruje wiadomość za pomocą swojego klucza prywatnego, każdy, kto ją posiada, może ją odszyfrować za pomocą klucza publicznego nadawcy. Zatem celem podpisu nie jest utrzymanie wiadomości w tajemnicy, ale sprawdzenie integralności / nadawcy wiadomości, to nie zostało zmienione.

W przypadku JWT system wysyłający jest zarówno twórcą, jak i odbiorcą wiadomości (patrz diagram poniżej), a celem jest upewnienie się, że token przekazany użytkownikowi nie został naruszony (np. Otrzymał podwyższone uprawnienia).

Jak wspomniano @Robert, JWT mogą / powinny być nadal szyfrowane za pomocą TLS.

Oto dobre wyjaśnienie JWT i podpisów, z których pochodzi poniższy obraz. 5 łatwych kroków do zrozumienia tokenów internetowych JSON (JWT)

— Micheasz B.
źródło

Aby dodać do odpowiedzi Roberta Harveysa, istnieje istotna wada szyfrowania ładunku - oznacza to, że odbiorca usługi musi udostępnić klucz tajny serwerowi uwierzytelnienia (kluczowi szyfrowania), aby zrozumieć, czy nośnik tokena jest autoryzowany, czy nie albo nie. Natomiast każdy może zweryfikować JWT przy użyciu tylko klucza publicznego opublikowanego przez serwer uwierzytelniający.

Jest to kluczowa część specyfikacji openid connect, ponieważ umożliwia aplikacjom klienckim sprawdzanie poprawności tokenów tożsamości wydanych przez serwer uwierzytelniania, a także ułatwia wdrażanie serwerów zasobów (ponieważ nie trzeba ich wdrażać z dostępem do tajnego szyfrowania) klucz), a także pomaga przy próbie zdiagnozowania problemów z wydanym JWT.

— Justin
źródło

Próbujesz porównać asymetryczne i symetryczne mechanizmy szyfrowania, jwt jest implementacją szyfrowania RSA.

— TheAnimatrix