Weryfikator JWT
Sprawdź, czy token internetowy JSON jest autentyczny i nadal ważny. Wklej token wraz z sekretem HMAC, kluczem publicznym PEM, certyfikatem, JWK lub całym JWKS. Weryfikator sprawdzi podpis za pomocą biblioteki jose, porówna exp i nbf z bieżącym czasem, uwzględniając opcjonalną tolerancję zegara, i poda jasny wynik obok zdekodowanego nagłówka i deklaracji. Tokeny z alg ustawionym na none są odrzucane.
Najczęściej zadawane pytania
Co sprawdza weryfikator?
Sprawdza podpis przy użyciu podanego klucza, a następnie porównuje deklaracje exp i nbf z bieżącym czasem. Wynik jest pozytywny tylko wtedy, gdy podpis jest zgodny i żadne ze sprawdzeń czasu nie wykazuje błędu. Deklaracje takie jak iss, aud lub sub są widoczne w ładunku, ale nie są porównywane z oczekiwanymi wartościami.
Jakie klucze mogę wkleić?
W przypadku HS256, HS384 i HS512 wklej współdzielony sekret jako tekst lub oct JWK. W przypadku tokenów RSA, EC i EdDSA wklej publiczny klucz PEM (SPKI lub PKCS #1), certyfikat X.509, publiczny lub prywatny JWK, JWKS zawierający do 50 kluczy albo prywatny klucz PEM, z którego używana jest tylko część publiczna.
Jak wybierany jest właściwy klucz z JWKS?
Jeśli nagłówek tokenu zawiera kid, używany jest klucz o takim samym kid w zestawie; jeśli nie ma dopasowania, pojawi się błąd wskazujący kid. Gdy kid nie występuje, zestaw musi zawierać dokładnie jeden klucz. Działa to tak samo, jak wybór kluczy przez większość serwerów na podstawie dokumentu jwks_uri.
Do czego służy opcja algorytmu?
Po wybraniu Use the token's alg algorytm jest pobierany z nagłówka tokenu, ale klucz nadal musi do niego pasować, więc publicznego klucza RSA nie można użyć jako sekretu HMAC. Wybierz konkretny algorytm, aby dodatkowo wymagać, by token go używał — tak serwer powinien przypinać oczekiwany algorytm. Token z innym alg zostanie odrzucony, a komunikat pokaże obie nazwy.
Dlaczego token z alg none jest odrzucany?
Token z alg none nie zawiera podpisu, więc nie ma czego weryfikować i każdy mógł go utworzyć. Akceptowanie takich tokenów to powszechna luka w bibliotekach JWT. Weryfikator zgłasza błąd zamiast zwracać prawidłowy wynik.
Jak działają exp, nbf i tolerancja zegara?
Token jest uznawany za wygasły, gdy exp przypada na bieżący czas lub wcześniej, a za jeszcze nieważny, gdy nbf przypada później. Tolerancja zegara od 0 do 3600 sekund rozszerza oba sprawdzenia, uwzględniając różnice wskazań zegarów między serwerami. Obecne roszczenia, które nie są liczbami, unieważniają token.
Co oznacza nieprawidłowy podpis?
Token nie został podpisany podanym kluczem albo jego nagłówek lub ładunek zmieniono po podpisaniu. Sprawdź, czy wklejono pasujący klucz publiczny lub sekret, z zachowaniem wszystkich znaków, i czy skopiowano cały token. Zdekodowany nagłówek i ładunek są nadal widoczne, aby można je było porównać.
Które algorytmy są obsługiwane?
HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512 oraz EdDSA z kluczami Ed25519. Klucze RSA muszą mieć co najmniej 2048 bitów. Zaszyfrowane tokeny (JWE) nie są odszyfrowywane.
Czy token lub klucz są przechowywane?
Nie. Token i klucz są używane wyłącznie do tej weryfikacji, w pamięci, i nigdy nie są rejestrowane ani zapisywane. Klucz publiczny można bezpiecznie udostępniać, ale z sekretami HMAC należy obchodzić się ostrożnie i zmienić każdy sekret, który mógł wyciec.
Jak duży może być token i klucz?
Token może mieć do 65,536 znaków, a pole klucza do 262,144 znaków, co pozwala wprowadzać duże dokumenty JWKS. Token musi składać się z trzech części base64url oddzielonych kropkami, zawierać nagłówek JSON z elementem alg oraz obiekt JSON jako ładunek.