[Yeboy]

Siema Mirasy!

Chciałbym zapytać Was o jedną rzecz. Otóż implementuje sobie w Spring Security filtr dla JWT. Wszystko wydaje mi się jasne prócz jednej kwestii, dosyć podstawowej.

Dotychczas myślałem, że dostęp do claimsów zawartych w JW Tokenie zabezpieczony jest tzw. signing key. W back-endzie, podczas generowania tokena, mam ustawione

.signWith(SignatureAlgorithm.HS512, - tutaj mój klucz przekonwertowany na byte[] -)

No i gitara, token zabezpieczony, klucz w formacie tablicy bajtów, elegancko.

Tu jednak rodzi mi się pytanko, dlaczego zatem, pomimo tego, że w back-endzie aby odczytać nawet podstawowe claimsy, jak np. username itd., muszę używać tego klucza:

Jwts.parser().setSigningKey( - tutaj mój klucz w formacie byte[] - ).parseClaimsJws(token).getBody();

ale już np. na stronce https://jwt.io/ bez problemu mogę dekodować mojego tokena i pozyskać z niego podstawowe informacje, jak poniżej na screenie.

Jak to w takim razie działa?

Z góry dzięki za pomoc.

#java

[globalbus]

@Yeboy: podpis to tylko weryfikacja, czy claimsy nie zostały podmienione. Jak chcesz szyfrować, to oddzielny klucz. Tylko zwykle nie ma po co szyfrować, a claimsy nie są tajne.

[srgs]

@Yeboy: poniewz 1 i 2 part to sa zakodowane do base64 surowe dane (json?). 3 czesc to dopiero podpis na i to to walidujesz (czy wszystkei czesci do siebie pasuja)
tak to ktos moglby wzaic stary token, wyedytowac part 1 albo 2 i 3 bez zmian i by dzialalo, no a raczej nie powinno.

[czepoI]

@Yeboy: payload jest przechowywany plaintextem jako json zakodowany za pomocą base64.

Ogólnie JWT token składa się z trzech części oddzielonej kropką. Payload znajduje się jako drugi element, czyli: eyJzdWIiOiJrdWJhIiwiZXhwIjoxNjY2Njk3NTU3LCJpYXQiOjE2NjY2ODc1NTd9

Co po zdekodowaniu daje:
{"sub":"kuba","exp":1666697557,"iat":1666687557}

Być może biblioteka, której używasz od razu robi walidację tj. czy sygnatura jest prawidłowa (token wystawiony przez uprawnioną stronę), a nie spreparowany

[Waffenek]

Być może biblioteka, której używasz od razu robi walidację

@czepoI: I bardzo dobrze. Ogólnie na backendzie nie powinno się nawet zerkać na token JWT bez sprawdzenia podatności sygnatury. W przeciwnym wypadku prosisz się o kłopoty bo można się zapomnieć i z rozpędu "uwierzyć na słowo" w to co przesłał klient. A coś takiego to ogromna dziura bezpieczeństwa. Należy przyjmować że broń jest zawsze załadowana a token przed rozparsowaniem podrobiony. Pierwsze co

[czepoI]

@Waffenek: zgadza się - wyjaśniałem tylko OP, dlaczego na jwt.io to działa ;)

[Waffenek]

@czepoI: Może moja wypowiedź niechcący zabrzmiała za ostro bo bardzo dobrze to wytłumaczyłeś. Chciałem tylko dodatkowo podkreślić jak istotne jest sprawdzenie sygnatury, tak żeby nikogo nie kusiło ręczne odczytywanie samego payloadu :)

[quwer]

@Waffenek: wyjasnisz dla mniej doswiadczonej osoby, czym jest odczytanie sygnatury i jak to zrobic?

[czepoI]

@Waffenek: w sumie dobrze, że zwróciłeś na to uwagę, bo ja za bardzo się skupiłem na wytłumaczeniu, dlaczego to może działać na JWT.io i lakonicznie tylko wspomniałem o sprawdzaniu czy token nie spreparowany, a jest to oczywiście kluczowe i bez tego token nie spełnia funkcji autoryzacji