JSON Web Tokens (JWT) - logika działania

Question

W niedawno zadanym pytaniu dostałem w odpowiedzi coś o nazwie JWT, co jest dokładnie tym czego potrzebowałem, tylko po przeczytaniu dość dużej ilości informacji na ten temat nie potrafie zrozumieć logiki działania owego tokenu.

 

Server jest przykładowo w Node.js, a aplikacja SPA vanilla JS.

Z klienta (aplikacji) jest tworzony token do servera z danymi logowania (Czy to server tworzy token dostępu? Jeśli tak dane logowania są wysyłane tylko przez samo https? metodą bruteforce wysyłając loginy i passy do api można utworzyć wiele tokenów dla użytkowników.).

Server tworzy owy token z certyfikatem, jak SPA lub aplikacja mobilna (cordova) z otwartym kodem ma sprawdzić poprawność certyfikatu jeśli w publicznym kodzie nie powinniśmy umieszczać sekretnego hasła do podpisu cyfrowego?

Jeśli to wciąż SPA tworzy token, jest dokładnie sam problem, żeby go stworzyć aby server mógł go sprawdzić sekretne hasło musi być umieszczone w kodzie, dostępnym.

Token jest generowany raz? Czy na każdy request a w nim dane?

 

Naprawdę byłbym wdzięczny za wytłumaczenie tego jak dziecku bo nie mogę zrozumieć jak to dokładnie działa.

Answer 1

1. Klient wysyła do serwera dobry login i hasło.
2. Serwer generuje jwt Access token oraz refresh token.
3. Access token jest wysyłany przy każdym requeście do serwera w nagłówku http. Nie jest zapisany w bazie danych, a przynajmniej zgodnie ze standardem nie powinien być.
4. Access token zawiera informacje dla którego użytkownika został wygenerowany. Ma też swój czas ważności.
5. Kiedy czas ważności minie serwer informuje o tym aplikację a ta wysyła refresh token i otrzymuje dzięki temu nowy Access token.
6. Refresh token jest zapisany w bazie i w razie kradzieży konta można go unieważnić. 

Oba te tokeny są kodowane base64, zawierają payload oraz header. Wszystkie muszą być podpisywane po stronie serwera, tak aby serwer przy każdym requeście weryfikował czy podpis się zgadza i czy dane w tokenie nie zostały zmienione.

Comments

Zrobiłem małą aplikację która działa w ten sposób i poprawiłem aby działała według logiki z twojego postu i jest to naprawdę świetne, wszystko działa jak powinno, obecnie czytam o refresh tokenach ponieważ stworzyłem tylko dostępowe (expire = destroy session/token).

 

Ale zastanawiam się, czy nie łatwiej byłoby po prostu wygenerować losowy ciąg znaków (~80 liczb) i po stronie servera przypisać do niego dane identyfikacyjne i zamiast narażania podpisów wysyłać sam token. JWT jest bardzo bezpieczne, ale losowy ciąg znaków i informacje po stronie servera także będą jeszcze bardziej oraz prostrze w kontroli, przynajmniej tak myślę, jeśli się mylę wyprowadź mnie z błędu.

I dzięki za powyższe wytłumaczenie, właśnie tego potrzebowałem.

---

Pierwszą złotą zasadą kryptografii jest: Nie rób sam kryptografii. ​​​​​​

Obecnie w PHP jest gotowa biblioteka to generowania tokenów JWT. 

https://github.com/firebase/php-jwt

---

Trzymanie jakichkolwiek informacji po stronie serwera automatycznie powoduje, że nie korzystasz z JWT. O tych tokenach serwer nie powinien pamiętać żadnych informacji. Z wyjątkiem klucza, który został użyty. To się nazywa stateless token.