Валидатор JWT
Проверете дали един JSON Web Token е автентичен и все още валиден. Поставете токена заедно с неговата HMAC тайна, публичен ключ PEM, сертификат, JWK или цял JWKS. Валидаторът проверява подписа с библиотеката jose, сравнява exp и nbf с текущото време и зададения допуск за часовника и показва ясен резултат до декодираното заглавие и твърденията. Токени с alg none се отказват.
Често задавани въпроси
Какво проверява валидаторът?
Той проверява подписа спрямо предоставения от вас ключ, след което сравнява твърденията exp и nbf с текущото време. Резултатът е валиден само ако подписът съвпада и нито една от проверките на времето не е неуспешна. Твърдения като iss, aud или sub се показват в полезния товар, но не се сравняват с очаквани стойности.
Какви ключове мога да поставя?
За HS256, HS384 и HS512 поставете споделената тайна като текст или oct JWK. За токени RSA, EC и EdDSA поставете публичен PEM ключ (SPKI или PKCS #1), сертификат X.509, публичен или частен JWK, JWKS с до 50 ключа или частен PEM ключ, от който се използва само публичната част.
Как се избира правилният ключ от JWKS?
Ако заглавката на токена съдържа kid, се използва ключът със същия kid в набора, а при липса на съвпадение грешката посочва kid. Без kid наборът трябва да съдържа точно един ключ. Това отразява начина, по който повечето сървъри избират ключове от документ jwks_uri.
Какво прави опцията за алгоритъм?
При Use the token's alg алгоритъмът се взема от заглавката на токена, но ключът все пак трябва да е подходящ за него, така че публичен RSA ключ никога не може да се използва като HMAC тайна. Изберете конкретен алгоритъм, за да изисквате и токенът да го използва — така сървърът трябва да фиксира очаквания си алгоритъм. Токен с друг alg се отхвърля, като се показват и двете имена.
Защо токен с alg none се отказва?
Токен с alg none не съдържа подпис, така че няма какво да се проверява и всеки би могъл да го създаде. Приемането на такива токени е добре позната уязвимост в JWT библиотеки. Проверяващият го отчита като грешка, а не като валиден резултат.
Как работят exp, nbf и допустимото отклонение на часовника?
Токенът се счита за изтекъл, когато exp е по-малко или равно на текущото време, и за все още невалиден, когато nbf е по-късно от текущото време. Допустимото отклонение на часовника от 0 до 3600 секунди разширява и двете проверки, за да отчете разминаване между часовниците на сървърите. Налични твърдения, които не са числови, правят токена невалиден.
Какво означава невалиден подпис?
Токенът не е подписан с предоставения ключ или заглавката или съдържанието му са променени след подписването. Проверете дали сте поставили съответстващия публичен ключ или тайна, включително точните му символи, и дали сте копирали целия токен. Декодираните заглавка и съдържание пак се показват, за да можете да ги сравните.
Кои алгоритми се поддържат?
HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512 и EdDSA с ключове Ed25519. RSA ключовете трябва да са с дължина поне 2048 бита. Криптирани токени (JWE) не се декриптират.
Съхраняват ли се токенът или ключът?
Не. Токенът и ключът се използват само за тази проверка в паметта и никога не се записват в дневник или съхраняват. Публичният ключ е безопасно да се споделя, но пазете HMAC тайните и сменете всяка тайна, за която подозирате, че е изтекла.
Колко големи могат да бъдат токенът и ключът?
Токените могат да са до 65,536 символа, а полето за ключ — до 262,144 символа, което позволява големи JWKS документи. Токенът трябва да има три base64url части, разделени с точки, заглавка JSON с член alg и обект JSON като съдържание.