[krasnoludkolo]

Jeszcze pytanie odnośnie JWT.

Generuje token z claimami w których jest username i password, wysyłam klientowi i on go potem przesyłam poprzez https więc nikt go po drodze nie podejrzy, ja go na serwerze sprawdzam czy został podpisany moim sekretnym słowem i jeśli tak to dekoduje playload, żeby zobaczyć kto wysyła?

#java #programowanie #webdev #kryptografia

[srgs]

@krasnoludkolo: pass w claimsach?¯\_(ツ)_/¯

[krasnoludkolo]

@srgs: kurde, myślałem że dobrze zrozumiałem ;/ to jak powinno to być?

[srgs]

Ktoś podaję login i pass ty sprawdzasz i jak jest poprawny zwracasz podpisany token. Późnej sprawdzasz podpis i daty w tokenie i jak jest poprawny to w tokenie masz np login user i na bazie tego ustawiasz kontext usera w security

[srgs]

@krasnoludkolo jw

[zajety_login]

@krasnoludkolo: Klient uderzając na Twój endpoint (np. na endpoint stricte przeznaczony do uwierzytelniania) dostarcza login i hasło (oczywiście komunikacja musi być szyfrowana). Ty po stronie backendu sprawdzasz czy wszystko jest cacy: jeżeli tak, to generujesz token JWT, w którym zapisujesz informacje, które później będą Ci potrzebne przy przetwarzaniu kolejnych requestów tego klienta. Oczywiście hasła w tokenie nie umieszczasz (bo nie musisz), a poprawność/ważność tokena sprawdzasz weryfikując jego podpis i datę.

[chester]

@krasnoludkolo: JWT to jest tylko sposób transportu tokena, a nie sposób autoryzacji.

1. Wysyłasz normalnie username/password do serwer przez JSON body
2. serwer generuje token JWT, w którym zawiera np {username:"", user_id:""}, ale *nie hasło*. Całość odsyła do klienta
3. klient w payload widzi informacje o userze (username i id) ale nie musi z nimi nic robić - korzysta jak z każdego innego tokena, przekazując go po prostu do serwera

[Roballo]

Czy sekretne słowo do podpisu musi być zawsze to samo? Czy coś się stanie jak po restarcie serwera będzie nowe? Klienci będą musieli się chyba tylko jeszcze raz zalogować, generując sobie nowy token? Nie będzie trzeba wtedy nigdzie trzymać tokenów

@krasnoludkolo: to zależy od kilku czynników m.in jak długo będzie żył taki token (dobrą praktyką jest to aby jak najkrócej, ale życie swoje, a teoria swoje), czy zmienisz "secretKey" w

[srgs]

@krasnoludkolo możesz użyć klucza prywatnego do podpisu i publicznego do weryfikacji bo w twoim przypadku masz tylko jeden klucz

[chester]

@krasnoludkolo: jeszcze to:
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
:)

[krasnoludkolo]

@Roballo: @srgs:

a jakby po prostu dać losowe UUID generowanie na starcie aplikacji?

[srgs]

@krasnoludkolo: jesali chodzi o bepieczenstwo to lepiej podpisac kluczem asymetrycznym, jak sie upierasz przy symetrycznym to mozesz uzyc czego kolwiek, byle mial odpowiednia dlugosc.
Na pewno potrzebujesz jwt?

[krasnoludkolo]

@srgs: potrzebuje czegoś co łatwo podpisze requesty.

Pisze dla mnie i grupy znajomych aplikacje do obstawiania wyników meczy i po prostu nie chce, żeby ktoś się podpisywał jako ktoś inny ;)

[krasnoludkolo]

@srgs: chodzi też, ze mam cały backend praktycznie napisany więc szukam jakiejś łatwej metody, żeby zabezpieczyć te endpointy które tego potrzebują, czyli dodanie nowego zakładu i update starego

[srgs]

@krasnoludkolo: podstawowa http sesion wystarczy do czegos takiego ++ spring security

[krasnoludkolo]

@srgs: nie używam springa (dobra chwilowo jeszcze jest, ale zaraz go nie będzie ;))

[krasnoludkolo]

@srgs: poza tym to projekt dla mnie, zawsze się czegoś nowego nauczę ;)

[Jurigag]

@krasnoludkolo: ogółem jak możesz to korzystaj z cookies/session i tyle, korzystanie z JWT tam gdzie to zbędne i niepotrzebne, tj jakaś prosta stronka to idiotyzm imho