Проверка на подпис на JSON Web Token (JWT)

Защо да проверявате подписа на JWT?

JSON Web Token (JWT) е разделен на три части, разделени с точки: header.payload.signature. Декодирането на JWT е просто въпрос на четене на първите две части (които са Base64URL). Всеки може да го направи и всеки моженаправи JWT с полезен товар по ваш избор. Това, което прави JWT надежден, е само подпис: без проверка, приемането на JWT е равносилно на допускане на всеки в дома ви, който се представя за някого, без да иска легитимация.

Този инструмент проверява подписа на JWT от ключ. Той не е доволен от декодиране: преизчислява подписа от заглавката, полезния товар и вашия ключ, след което го сравнява с подписа на токена. Ако двете съвпадат, токенът е автентичен. Иначе беше изковано, модифицирани или подписани с друг ключ.

Проверката е крайъгълният камък на всяка архитектура, която използва JWT за удостоверяване или оторизация: без валиден подпис полезният товар може да излъже. Нападател, който променя "role":"user" на "role":"admin", няма да има трудности при това, ако сървърът провери само формата на токена, а не неговия подпис.

Общи алгоритми

Спецификацията JWT (RFC 7518, JSON уеб алгоритми) дефинира няколко семейства алгоритми. Ето го най-използваните в производството:

• HMAC (HS256, HS384, HS512): симетричен подпис, базиран на HMAC-SHA. The Същият таен ключ се използва за подписване и проверка. Лесен за настройка, ефикасен, но всяка страна, способна да провери токена, също е в състояние да го издаде. Адаптиран към сценарии, при които издателят и проверяващият са един и същи екип или отдел.
• RSA (RS256, RS384, RS512): асиметричен подпис. Личният ключ знак, публичният ключ проверява. Идеален, когато предавателят и Верификаторите са отделни обекти (OAuth2, OpenID Connect, Identity Federation). това е алгоритъмът, предпочитан от повечето доставчици на публична идентичност.
• ECDSA (ES256, ES384): асиметричен подпис върху елиптични криви. Същата логика като RSA (частен ключ за подписване, публичен ключ за проверка), но с ключове и по-компактни подписи за еквивалентно ниво на сигурност. Все по-разпространени в модерни архитектури.

Как да предоставим ключа

Форматът на очаквания ключ зависи от алгоритъма, деклариран в JWT заглавката:

• HS256, HS384, HS512: ключът е таен низ (низ). Това е тайната, споделена с емитента, често съхранявана в променлива на средата като JWT_SECRET. Без специално форматиране, само необработената стойност.
• RS256, RS384, RS512: ключът е RSA публичен ключ във формат PEM, който започва с -----BEGIN PUBLIC KEY----- и завършва с -----КРАЙ НА ПУБЛИЧНИЯ КЛЮЧ-----. Запазете новите редове такива, каквито са, в противен случай OpenSSL отказва да го анализира.
• ES256, ES384: ключът е ECDSA публичен ключ във формат PEM, върху съответната крива (P-256 за ES256, P-384 за ES384).

Пример за очакван RSA публичен ключ

-----НАЧАЛО НА ПУБЛИЧЕН КЛЮЧ-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx...
...vQIDAQAB
-----КРАЙ НА ПУБЛИЧНИЯ КЛЮЧ-----

Как работи проверката?

Нашият сървър възпроизвежда точно операцията, извършена от предавателя:

1. Разделя JWT на заглавка, полезен товар и подпис.
2. Свързва base64url(header) + "." + base64url(полезен товар).
3. За HMAC изчислява HMAC-SHA-256/384/512 с вашия таен ключ, след което сравнява с подпис, получен чрез hash_equals (сравнение на постоянно време за избягване на атаки време).
4. За RSA извиква openssl_verify с вашия публичен ключ във формат PEM.

Случаи на употреба

• Отстраняване на грешки при удостоверяване на API: получавате 401, проверете дали вашият токен е добре подписан с очаквания ключ.
• Потвърждение на токен, получен от доставчик: партньор (Auth0, Keycloak, Cognito, Okta) ви изпраща JWT, подписани в RS256; искате да потвърдите, че идват от от него с неговия публичен ключ.
• Проверка на сигурността: проверете дали услуга на трета страна подписва правилно своите токени със стабилен алгоритъм, а не в HS256 с ниска секретност.
• Ръчни тестове: проверете дали JWT, генериран от вашия код, преминава проверка с предоставения публичен ключ.
• Бърза проверка на получен токен: по време на интегрирането на SSO или Партньорски API, проверете след няколко секунди дали подписът/ключовата верига работи преди да напишете и най-малкия ред код.

Как да използвате инструмента

1. Поставете целия JWT (трите части, разделени с точки).
2. Посочете ключа, адаптиран към алгоритъма на заглавката:
   • За HS256, HS384 или HS512 ключът е тайният низ споделен зас предавателя. Това е свободен низ, често съхраняван в a променлива на средата като JWT_SECRET.
   • За RS256, RS384 или RS512 ключът е публичният ключ във формат PEM, който започва с -----BEGIN PUBLIC KEY----- и завършва с -----КРАЙ НА ПУБЛИЧНИЯ КЛЮЧ-----.
3. Изпълнете проверката. Инструментът показва състоянието (валиден или невалиден) и декодирания полезен товар.

Често срещани клопки, които трябва да избягвате

• Алгоритъм „няма“: спецификацията позволява alg: няма, което означава „не подпис“. Класическият недостатък се състои в създаването на токен с тази заглавка, надявайки се, че сървърът го приема. Нашият инструмент систематично отхвърля жетони с alg: няма.
• HMAC срещу RSA объркване (объркване на алгоритъм): нападател променя алгоритъма RS256 към HS256 и подписва полезния товар с използвания публичен RSA ключ като тайна на HMAC. Ако сървърът не контролира алгоритъма, той приема токена. Винаги заключете очаквания алгоритъм от страната на сървъра.
• Твърдо кодирани тайни на HMAC: рендира се тайна, ангажирана в Git хранилище цялото доверие в токените е изчезнало. Съхранявайте тайни в променливи на средата или безопасно приложение.
• Публичен ключ срещу частен ключ: за да проверим JWT, подписан в RSA или ECDSA, ние предоставя публичния ключ, никога частния. Частният се използва само за подписване и не го прави никога не трябва да излиза от предавателя.
• Игнорирано изтичане: валиден подпис върху изтекъл токен не трябва никога не се приемат. Не забравяйте да проверите exp и nbf.
• Неконтролирана аудитория: токен, предназначен за API A, не трябва да се приема от API B. Проверете твърдението aud.

Времеви искове: exp и nbf

Освен подписа, валидният JWT трябва също да спазва своите времеви ограничения:

• exp (изтичане): токенът вече не е валиден след тази дата.
• nbf (не преди): токенът все още не е валиден преди тази дата.

Нашият инструмент изрично сигнализира, когато токен е изтекъл или все още не валидени дори подписът му да е правилен. Това е важно: валиден подпис на a Изтеклият токен никога не трябва да се приема в производството.

Разлика с нашия JWT декодер

Нашият JWT декодер просто декодира заглавката и полезен товар, за да ги направи четими. Не извършва никаква проверка на подписи не искай ключ. Използвайте го, за да проверите бързо съдържанието на токен. Използвайте JWT верификатор (тази страница), когато трябва да докажете, че токенът е автентичен. За да направите подписан JWT за тестване, използвайте нашия JWT builder.

Често задавани въпроси

Пример за заявка

curl -X POST https://cdrn.fr/api/v1/tools/jwt-verifier/execute \
  -H "Content-Type: application/json" \
  -d '{"token":"...","key":"..."}'

Входна схема

Крайни точки

• GET https://cdrn.fr/api/v1/tools - изброява всички достъпни инструменти
• GET https://cdrn.fr/api/v1/tools/jwt-verifier - извлича схемата на този инструмент
• POST https://cdrn.fr/api/v1/tools/jwt-verifier/execute - изпълнява този инструмент с JSON payload