Generator JWT

Generator obsługuje HS256, HS384 i HS512 ze współdzielonym sekretem; RS256, RS384, RS512, PS256, PS384 i PS512 z prywatnym kluczem RSA; ES256, ES384 i ES512 z prywatnym kluczem EC na krzywej P-256, P-384 lub P-521; oraz EdDSA z prywatnym kluczem Ed25519. Wybrany algorytm jest zapisywany w nagłówku alg, a typ jest zawsze ustawiony na JWT.

Wprowadź obiekt JSON zawierający deklaracje, na przykład sub, name, iss, aud lub dowolne własne pole. Tablice, ciągi znaków i inne wartości, które nie są obiektami, są odrzucane, ponieważ ładunek JWT musi być obiektem JSON. Kolejność deklaracji i ich wartości pozostają dokładnie takie, jak je wpisano.

W przypadku HS256, HS384 i HS512 sekret jest używany jako tekst UTF-8 po usunięciu białych znaków z początku i końca. Jeśli sekret ma postać binarną, wklej go jako JWK, na przykład {"kty": "oct", "k": "..."}, z bajtami zakodowanymi w base64url; zamiast tekstu zostaną użyte zdekodowane bajty. Klucze PEM są odrzucane w przypadku algorytmów HMAC, ponieważ używanie klucza publicznego jako sekretu HMAC to częsty błąd.

RFC 7518 wymaga klucza o długości co najmniej równej długości wyniku funkcji skrótu, czyli 32 bajtów dla HS256, 48 dla HS384 i 64 dla HS512. Narzędzie podpisuje tokeny także krótszymi sekretami, aby umożliwić odtworzenie tokenów testowych, ale sekrety produkcyjne powinny być długimi, losowymi wartościami, na przykład wygenerowanymi przez Generator haseł.

Wklej niezaszyfrowany klucz prywatny PEM w formacie PKCS #8 (BEGIN PRIVATE KEY), PKCS #1 (BEGIN RSA PRIVATE KEY) lub SEC1 (BEGIN EC PRIVATE KEY), albo prywatny JWK zawierający element d. Zaszyfrowane pliki PEM i klucze prywatne OpenSSH nie są odczytywane. Klucz musi pasować do algorytmu, więc ES384 wymaga klucza P-384, a klucze RSA muszą mieć co najmniej 2048 bitów.

Gdy opcja czasu wydania jest włączona, iat jest ustawiane na bieżący czas, chyba że ładunek zawiera już deklarację iat. Gdy czas wygaśnięcia jest większy niż 0 sekund, exp jest ustawiane na bieżący czas plus podaną liczbę sekund i zastępuje każdą wartość exp z ładunku. Przy czasie wygaśnięcia równym 0 exp nie jest dodawane, a wartość exp z ładunku zostaje zachowana.

Niepusty identyfikator klucza jest zapisywany w nagłówku kid, aby weryfikatory mogły wybrać właściwy klucz z JWKS. Jeśli jako klucz podpisujący wkleisz JWKS, kid wybierze również klucz z tego zestawu, którym zostanie podpisany token. Konwerter JWK i generatory kluczy pokazują odcisk palca RFC 7638, który dobrze nadaje się na kid.

Otrzymujesz zwarty token, algorytm, identyfikator klucza, czasy wydania i wygaśnięcia w UTC oraz dokładne JSON nagłówka i ładunku, które zostały podpisane. Skopiuj token z pierwszego bloku. Później zdekoduj go ponownie za pomocą dekodera JWT lub sprawdź go w weryfikatorze JWT.

Nie. Sekret lub klucz prywatny jest przesyłany wyłącznie w żądaniu podpisującym token, używany raz w pamięci i nigdy nie jest zapisywany w logach ani przechowywany. Mimo to do eksperymentów używaj kluczy testowych i nigdy nie wklejaj produkcyjnego klucza podpisującego do żadnego narzędzia internetowego, chyba że kontrolujesz serwer.

Ładunek może mieć maksymalnie 65,536 znaków, klucz 65,536 znaków, a kid 256 znaków. Czas wygaśnięcia może wynosić od 0 do 315,360,000 sekund, czyli dziesięciu lat. Dłuższe dane są odrzucane, a komunikat wskazuje nazwę pola.