logo
GeekFormat

JWT

Encoded Token172 charsОбновлено 2026-07
header
payload
signature
Valid JWTHS256
Secret38 chars
Header
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}
Claims details4 items
sub· Субъект1234567890
name· NameJohn Doe
admin· Admintrue
iat· Время выпуска151623902218.01.2018, 09:30:22
Header details2 items
algHS256HMAC (симметричный)
typ· TypeJWT
All operations run locally in your browser; the Token and key are never sent to any server.

Бесплатный онлайн-инструмент для JWT: декодирование, валидация и генерация JWT Token. Просмотр Header, Payload и подписи для отладки аутентификации API.

Похожие

Варианты использования

  • Онлайн-декодирование JWT: быстрое разделение токена при отладке входа OAuth 2.0 / OIDC для проверки алгоритма Header и Claims Payload
  • Проверка подписей JWT: используйте секретный ключ / публичный ключ для проверки подписей токенов в реальном времени и определения, является ли 401 'плохой подписью', 'истекшим' или 'несоответствием алгоритма'
  • Генерация тестовых JWT во время интеграции: выпустите JWT в браузере с тестовой парой ключей, без необходимости временно изменять код backend для выдачи токена
  • Конвертация PEM ↔ JWK: OIDC IdP дал вам JWK, но серверу нужен PEM (или наоборот) — конвертируйте на месте вместо написания скрипта OpenSSL
  • Диагностика 401 Unauthorized: пошагово проверяйте истечение срока, соответствие alg шлюзу, соответствие ключа и форматирование PEM
  • Сравнение RS256 и PS256: многие провайдеры OIDC по умолчанию используют RS256, тогда как AWS SigV4 предпочитает PS256 — переключайте алгоритмы с той же парой ключей RSA и сравнивайте результаты
  • Изучение внутренностей JWT: измените alg, отредактируйте Payload, переключите ключ в браузере и наблюдайте, как подпись ломается в реальном времени — намного быстрее, чем чтение RFC

Функции

  • Декодирование + Проверка + Генерация в одном месте: вставьте токен, чтобы разделить Header/Payload/Signature, переключите алгоритм и ключ для проверки подписи, отредактируйте Claims и подпишите заново, чтобы создать новый токен — покрывает полную цепочку устранения неполадок JWT
  • Поддерживаются все 13 алгоритмов: HS256/HS384/HS512 (HMAC), RS256/RS384/RS512 (RSA-PKCS1-v1_5), ES256/ES384/ES512 (ECDSA), PS256/PS384/PS512 (RSA-PSS), EdDSA — покрывает OAuth 2.0, OIDC, JWS, API-шлюзы и корпоративные SSO
  • Форматы PEM и JWK: ключи RSA, ECDSA и Ed25519 принимают строки PEM (с заголовками -----BEGIN PUBLIC KEY-----) и JSON JWK (поля kid/kty/n/e) — вставьте напрямую вывод OIDC /.well-known/jwks.json
  • Множество форм ввода секретного ключа HMAC: необработанная строка UTF-8, hex-байты или кодированный Base64/Base64URL — переключайте одним кликом, чтобы никогда не случалось 'выглядит так же, но подпись не проходит'
  • Автоматическая генерация пар ключей: пары ключей RSA-2048, RSA-4096, P-256, P-384 и Ed25519 генерируются в браузере, представлены в форматах PEM и JWK для немедленного использования в тестах
  • Семантическое выделение Claims: exp / iat / nbf автоматически конвертируются в читаемое время с выделенным статусом истек / еще-не-действителен / выдан; alg / typ / kid в Header помечены индивидуально
  • 100% на стороне клиента, нулевая загрузка: каждый парсинг, проверка и подпись работают через нативный Web Crypto API браузера — токены, ключи и payload никогда не покидают браузер, следуя принципу безопасности 'никогда не вставляйте production-токены в случайные онлайн-инструменты'
  • Копирование одним кликом: Header, Payload, Signature и только что сгенерированный токен копируются независимо для документации, тикетов и команд curl

Как использовать

  1. Вставьте или введите токен: поместите строку JWT в поле ввода; инструмент автоматически разделит Header, Payload и Signature и отобразит каждый как отформатированный JSON
  2. Выберите алгоритм: переключайтесь между HS256 / RS256 / ES256 / PS256 / EdDSA; инструмент выводит из Header.alg и помечает любые несоответствия
  3. Импортируйте ключ: вставьте секретный ключ HMAC, строку PEM или JSON JWK; для асимметричных алгоритмов нажмите 'Сгенерировать пару ключей', чтобы немедленно получить тестовый ключ
  4. Проверьте или подпишите заново: в режиме Decode проверяйте публичным ключом и смотрите '✅ подпись действительна / ❌ подпись недействительна'; в режиме Encode редактируйте Claims и подписывайте приватным ключом, чтобы создать новый токен

Часто задаваемые вопросы

Каковы три части JWT?

Строка JWT имеет форму `Header.Payload.Signature`, каждый сегмент закодирован в Base64URL. Header объявляет алгоритм (например, HS256, RS256) и тип токена (typ: JWT); Payload несет Claims пользователя (заявления), общие поля: sub (ID пользователя), iat (время выдачи), exp (время истечения), nbf (not-before), aud (аудитория), iss (эмитент); Signature является результатом подписания первых двух сегментов ключом, цель — 'обнаружение подделки', а не 'анти-утечка'.

Могу ли я редактировать Payload после декодирования?

Вы можете просматривать и редактировать, но **не подделывать**. Как только вы измените Header или Payload, оригинальная Signature станет недействительной, и сервер отклонит проверку. Чтобы модифицированный токен снова стал действительным, вы должны **переподписать** его тем же алгоритмом и тем же ключом — именно поэтому этот инструмент предлагает 'декодирование + редактирование + генерацию' в одном: декодируйте для просмотра, измените и немедленно сгенерируйте новый токен для тестирования, чтобы вам не нужно было каждый раз просить backend временно изменить код для выдачи.

В чем разница между HS256, RS256, ES256, PS256 и EdDSA?

HS256 использует HMAC с общим секретным ключом (симметричный), быстрый, но управление секретным ключом критично. RS256 использует приватные/публичные ключи RSA (асимметричный), эмитент подписывает приватным, проверяющий использует публичный. ES256 использует ECDSA с эллиптическими кривыми (P-256), более короткая подпись. PS256 использует RSA-PSS, безопаснее RS256. EdDSA (обычно Ed25519) быстрый и детерминированный, рекомендуется для OAuth 2.1.

Почему мой JWT продолжает показывать 'Invalid Signature'?

Обычно это потому, что ключ, формат секретного ключа, алгоритм или кодировка Base64URL не совпадают точно. Дополнительный пробел, неправильная новая строка PEM или путаница между Base64 и Base64URL достаточны. Проверьте байт за байтом и подтвердите, что Header.alg соответствует выбранному алгоритму.

Может ли один и тот же ключ RSA перекрестно проверять RS256 и PS256?

Нет. RS256 использует RSASSA-PKCS1-v1_5, PS256 использует RSA-PSS. Даже с одним и тем же ключом RSA они не могут перекрестно проверять. Подписант и проверяющий должны использовать один и тот же алгоритм.

Что такое атака alg:none?

Атакующий меняет Header на `{"alg":"none"}` (без подписи) или заменяет RS256 на HS256 (используя публичный ключ, как если бы он был секретным ключом HMAC). Сервер должен навязать белый список алгоритмов и никогда не позволять токену решать, какой алгоритм использовать.

Как я конвертирую между PEM и JWK?

PEM — это классическая нотация OpenSSL с строками BEGIN/END. JWK — это JSON и он распространен в OAuth/OIDC. OIDC-провайдеры часто публикуют публичные ключи через `/.well-known/jwks.json`. Этот инструмент может напрямую обрабатывать форматы PEM и JWK.

Может ли браузер напрямую проверять подписи JWT?

Да. Нативный Web Crypto API браузера (`window.crypto.subtle`) поддерживает подпись и проверку HMAC, RSA, ECDSA, RSA-PSS и Ed25519, без сторонних библиотек. Этот инструмент использует `crypto.subtle.importKey` и `crypto.subtle.verify` на фронтенде для каждой проверки, поэтому никогда не отправляет ваши токены или ключи. Примечание: Web Crypto доступен только в безопасных контекстах: **HTTPS** или `localhost`.

Мой токен отправляется на сервер?

Нет. Весь парсинг, проверка и подпись в этом инструменте работают в браузере через нативный Web Crypto API. Токен, Header, Payload, Signature, секретный ключ / приватный ключ и любые сгенерированные пары ключей никогда не отправляются на сервер. Откройте вкладку Network DevTools браузера, и вы не увидите исходящего запроса, несущего содержимое токена. Страница может использоваться офлайн после загрузки.

Является ли JWT безопасным местом для чувствительной информации о пользователе?

**Нет.** Payload JWT по умолчанию является открытым текстом — любой с токеном может декодировать его в Base64URL и прочитать содержимое. Шифрования нет. **Никогда не помещайте** пароли, национальные ID-номера, номера кредитных карт, API-ключи, access-токены или refresh-токены в открытом виде в JWT. Если вам нужно шифрование, используйте JWE (RFC 7516) вместо JWS. JWT подходят для нечувствительных Claims (ID пользователя, роль, время истечения, ID арендатора); чувствительные данные должны запрашиваться на стороне сервера с использованием `sub`.

Что такое Декодирование, Проверка и Генерация JWT?

JWT (JSON Web Token) — это открытый стандарт, определенный IETF в RFC 7519 (RFC 7515 описывает форму подписи JWS, RFC 7516 описывает шифрование JWE, RFC 7517 определяет ключи JWK) для безопасной передачи 'заявленной' информации о пользователе между HTTP-запросами, потоками OIDC и вызовами микросервисов. Стандартная строка JWT состоит из трех сегментов, закодированных в Base64URL: Header (алгоритм и тип), Payload (Claims, данные пользователя) и Signature (подпись на основе ключа над первыми двумя). Три сегмента соединены точкой `.`, например `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.

**JWT — это не шифрование.** Это самое распространенное заблуждение. Payload по умолчанию является открытым текстом — любой может декодировать его в Base64URL и прочитать содержимое. JWT обеспечивает **обнаружение подделки**, а не конфиденциальность: сервер переподписывает Header.Payload общим ключом и сравнивает с Signature токена. Если они совпадают, токен не был изменен при передаче. Это метафора 'железнодорожного билета с антиподдельным штампом': инспектору важно, настоящий ли билет, а не читаем ли QR-код.

JWT четко разделяет ответственность между 13 алгоритмами. **Семейство HMAC** (HS256/HS384/HS512) использует симметричный ключ для подписи и проверки, быстрое и простое, подходит для одного сервиса или доверенного кластера; секретный ключ должен быть как минимум длиной дайджеста (например, ≥ 32 байт для HS256). **Семейство RSA** (RS256/RS384/RS512) использует RSASSA-PKCS1-v1_5, наиболее распространенную асимметричную схему — подписанты имеют приватный ключ, проверяющие имеют публичный ключ. **Семейство RSA-PSS** (PS256/PS384/PS512) использует более новый padding RSA-PSS с более сильными гарантиями безопасности, предпочитается AWS SigV4 и современными провайдерами идентификации OIDC. **Семейство ECDSA** (ES256/ES384/ES512) использует эллиптические кривые (P-256/P-384/P-521 соответственно) с более короткими подписями и лучшей производительностью. **EdDSA** (в основном Ed25519) чрезвычайно быстр и детерминирован (одно и то же сообщение + один и тот же ключ = одна и та же подпись каждый раз) и является рекомендуемым алгоритмом в OAuth 2.1 и новых протоколах.

Безопасность — это то, где JWT спотыкается в production. OWASP JWT Cheat Sheet перечисляет как минимум четыре жестких правила: (1) никогда не помещайте пароли, национальные идентификационные документы, номера карт или API-ключи как открытый текст в Payload; (2) сервер должен **никогда не доверять полю alg**, объявленному в Header Токена — должен проверять с жестко закодированным алгоритмом, иначе атакующий, переписывающий заголовок на `alg: none`, обходит все (это источник исторических CVE, таких как CVE-2015-9235); (3) секретные ключи HMAC должны быть случайными и иметь как минимум 32 байта, никогда короткие строки; (4) проверка — это больше, чем просто проверки подписи — вы также должны валидировать `exp` (истечение срока), `nbf` (not-before), `iss` (эмитент) и `aud` (аудитория). Этот инструмент выделяет каждый из этих Claims в UI, чтобы вы могли сразу увидеть, является ли сбой проблемой подписи, проблемой времени или проблемой Claims.

JWT не заменяет сессии. Сессии хранят состояние пользователя на сервере (Redis или база данных); JWT упаковывает состояние в токен. Архитектуры микросервисов, stateless API, мобильные клиенты и конфигурации с большим количеством CORS выигрывают от JWT; традиционные корпоративные системы и потоки, требующие мгновенного отзыва (например, 'выгнать этого пользователя сейчас'), по-прежнему лучше обслуживаются сессиями. Этот инструмент охватывает как чистую отладку JWT, так и шаги парсинга Токена / проверки подписи / редактирования Payload миграции с сессий на JWT.

Code Examples

50 lines of Node.js: hand-written HS256 sign and verify

javascript

Distills JWT's core mechanism: encode Header and Payload in Base64URL, then HMAC-SHA256 the `header.payload` string. In production, use a library like jsonwebtoken or jose — this snippet exists to make signature failures debuggable.

const crypto = require('node:crypto')

function b64url(input) {
  return Buffer.from(input)
    .toString('base64')
    .replace(/\+/g, '-')
    .replace(/\//g, '_')
    .replace(/=+$/, '')
}

function hmacSign(data, secret) {
  return b64url(crypto.createHmac('sha256', secret).update(data).digest())
}

function sign(payload, secret) {
  const header = b64url(JSON.stringify({ alg: 'HS256', typ: 'JWT' }))
  const body = b64url(JSON.stringify(payload))
  const signature = hmacSign(`${header}.${body}`, secret)
  return `${header}.${body}.${signature}`
}

function verify(token, secret) {
  const [h, p, s] = token.split('.')
  const expected = hmacSign(`${h}.${p}`, secret)
  const a = Buffer.from(s)
  const b = Buffer.from(expected)
  return a.length === b.length && crypto.timingSafeEqual(a, b)
}

const SECRET = 'my-super-secret-key'
const payload = { userId: 42, role: 'admin', exp: Math.floor(Date.now() / 1000) + 3600 }
const token = sign(payload, SECRET)

console.log(token)
console.log(verify(token, SECRET))       // true
console.log(verify(token, 'wrong-key'))  // false

Browser-side: Web Crypto API for HMAC signing

html

The core idea of this tool's front-end: use the browser's native crypto.subtle for HMAC, RSA, ECDSA, RSA-PSS and Ed25519 verification — no third-party library needed. Drop this into any HTML page to mint HS256 tokens.

<!doctype html>
<html>
  <body>
    <pre id="out"></pre>
    <script>
      const out = document.getElementById('out')

      const b64url = buf =>
        btoa(String.fromCharCode(...new Uint8Array(buf)))
          .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

      const b64urlStr = str => b64url(new TextEncoder().encode(str))

      async function sign(payload, secret) {
        const header = b64urlStr(JSON.stringify({ alg: 'HS256', typ: 'JWT' }))
        const body = b64urlStr(JSON.stringify(payload))
        const data = new TextEncoder().encode(`${header}.${body}`)

        const key = await crypto.subtle.importKey(
          'raw',
          new TextEncoder().encode(secret),
          { name: 'HMAC', hash: 'SHA-256' },
          false,
          ['sign']
        )

        const sig = await crypto.subtle.sign('HMAC', key, data)
        return `${header}.${body}.${b64url(sig)}`
      }

      ;(async () => {
        const token = await sign({ user: 'alice', role: 'admin' }, 'browser-demo-secret')
        out.textContent = token
      })()
    </script>
  </body>
</html>

Node.js: verify RS256 with jose (the right way)

javascript

Use a mature library like jose, jsonwebtoken, or PyJWT in production — never roll your own. This snippet shows how jose verifies an RS256 token, prints the failure reason on error (alg mismatch, bad signature, expired, kid not found, etc).

import { jwtVerify, importSPKI } from 'jose'
import { readFile } from 'node:fs/promises'

const token = 'eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.payload.signature'
const publicKeyPem = await readFile('public.pem', 'utf8')

try {
  const { payload, protectedHeader } = await jwtVerify(
    token,
    await importSPKI(publicKeyPem, 'RS256'),
    {
      issuer: 'https://idp.example.com',
      audience: 'my-app',
      algorithms: ['RS256'],     // critical: algorithm whitelist blocks alg:none and HS256-substitution attacks
    }
  )
  console.log('alg =', protectedHeader.alg)
  console.log('sub  =', payload.sub)
} catch (err) {
  console.error('verify failed:', err.code, err.message)
  // common: ERR_JWT_EXPIRED / ERR_JWS_INVALID / ERR_JWS_SIGNATURE_VERIFICATION_FAILED
}

Python: parse a token and print its Claims with PyJWT

python

The most common way to debug JWT on the Python side. PyJWT's decode() validates exp / nbf / iat by default and returns the result as a plain dict.

import jwt

token = 'eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxw'

# Parse (no signature check, just look at Header and Payload)
print(jwt.get_unverified_header(token))
# {'alg': 'HS256', 'typ': 'JWT'}

print(jwt.decode(token, options={'verify_signature': False}))
# {'sub': '1234'}

# Full verification
claims = jwt.decode(
    token,
    'my-super-secret-key',
    algorithms=['HS256'],
    audience='my-app',
    issuer='my-service',
)
print(claims['sub'])

Supported Video Formats

FormatMIMEBrowser supportWhen to use
HS256 / HS384 / HS512HMAC + SHA-256/384/512UniversalАлгоритм с симметричным ключом: один и тот же Secret используется и для подписи, и для проверки. Он простой и быстрый, хорошо подходит для кластера сервисов внутри доверенной зоны. Secret должен быть не короче 32 байт для HS256, 48 для HS384 и 64 для HS512.
RS256 / RS384 / RS512RSASSA-PKCS1-v1_5 + SHA-2Web Crypto APIСамый распространенный асимметричный алгоритм. Подпись создается закрытым ключом, а проверяется открытым. Это типичный выбор для OIDC-провайдеров, API gateway и корпоративного SSO.
PS256 / PS384 / PS512RSA-PSS + SHA-2Web Crypto APIRSA-PSS — более современная и безопасная замена RS256. AWS SigV4, AWS Cognito и современные OIDC-провайдеры часто выбирают именно его. saltLength нужно задавать явно, иначе проверка может не совпасть.
ES256 / ES384 / ES512ECDSA + P-256/P-384/P-521Web Crypto APIПодписи на эллиптических кривых. Они короче (ES256 занимает всего 64 байта), работают быстро и уменьшают размер JWT. Sign in with Apple по умолчанию использует ES256.
EdDSA (Ed25519)Ed25519 / Ed448Web Crypto APIСовременный высокопроизводительный алгоритм подписи. Подписи детерминированы (одно сообщение + один ключ = одна и та же подпись), нет риска повторного nonce, поэтому он хорошо подходит для новых протоколов.

Output Example

A real MP3 file encoded to a Data URI — copy-ready:

Header (Base64URL): eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Payload (Base64URL): eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzE2MjM5MDIyfQ
Signature: kZJfaYjK3iCkVFL5EL9zGRZ5SmD8_x2h6B5c7pVFfVGo

Privacy & Security

Эта рабочая среда JWT работает на 100% в вашем браузере, поддерживается нативным Web Crypto API браузера. Токен, который вы вставляете, Header, Payload, Signature, секретный ключ HMAC, любые приватные ключи RSA/ECDSA, любые сгенерированные пары ключей и каждый расчет подписи/проверки остаются на вашем устройстве — они никогда не отправляются на сервер, никогда не логируются, никогда не анализируются и никогда не кэшируются. Страница может использоваться офлайн после загрузки. Лучшая практика: никогда не вставляйте долгоживущие production-токены или production-приватные ключи в какой-либо онлайн-инструмент, включая этот. Этот инструмент подходит для отладки, тестирования интеграции, обучения и генерации тестовых токенов — production-секретные ключи и приватные ключи должны обрабатываться в контролируемой локальной среде.

Authoritative References

Troubleshooting

Invalid Signature: 'signature is invalid'

Токен и ключ проверки не совпадают. Обычные причины: (1) ключ сервера и ключ, который вы вставили в инструмент, различаются (самое частое); (2) ключ содержит невидимые символы (пробел в конце, новая строка, символ нулевой ширины); (3) Base64 и Base64URL перепутаны; (4) выбран неправильный алгоритм (Header говорит HS256, сервер проверяет как RS256 или наоборот). Сначала проверьте, совпадает ли ключ байт за байтом: обратите внимание на конечные новые строки PEM, конечные пробелы секретного ключа HMAC и значения `k` JWK, которые могли быть неправильно декодированы URL. Подтвердите, что алгоритм в инструменте соответствует Header.alg токена. Используйте decode-plus-verify этого инструмента, чтобы воспроизвести точную ошибку и подтвердить, что она происходит между 'декодирование успешно' и 'проверка не удалась'.

HTTP 401 Unauthorized: Token Expired или iat в будущем

Проверка подписи прошла, но `exp` находится в прошлом (Token Expired), `nbf` все еще в будущем (Not Before) или `iat` позже текущего времени сервера (часто из-за рассинхронизации часов). Другой распространенный случай — несовпадающий `aud` (аудитория): токен был выпущен для Приложения A, но проверен Приложением B. Используйте выделенную область Claims в этом инструменте, чтобы сразу увидеть статус exp / nbf / iat. Красный exp = истек, перевыпустите. Красный nbf = еще не действителен, проверьте, является ли iat будущим временем. Красный aud = неправильная аудитория, проверьте, правильно ли настроена аудитория на сервере.

Ошибка импорта PEM или JWK

PEM имеет дополнительные пустые строки или отсутствуют маркеры заголовка/подвала (`-----BEGIN PUBLIC KEY-----`); JWK отсутствуют обязательные поля (`kty` / `n` / `e` / `kid`); значение `k` JWK отсутствует padding Base64URL (должен быть заполнен `=` или строго без `=`); приватный ключ RSA импортируется как публичный ключ; приватный ключ Ed25519 (32-байтовое зерно) предоставляется как 64 байта. Переэкспортируйте стандартный PEM PKIX с помощью `openssl rsa -in key.pem -pubout -outform PEM` или `openssl ec -in key.pem -pubout`; для JWK используйте необработанный вывод из эндпоинта OIDC Discovery `/.well-known/jwks.json` вместо ручного кодирования. Этот инструмент автоматически обнаруживает заголовки PEM, отсутствующий padding и отсутствующие поля JWK и дает подсказку.

RS256 и PS256 сбои подписи между языками

RS256 использует RSASSA-PKCS1-v1_5, PS256 использует RSA-PSS. Эти два **не могут перекрестно проверять** — токен, подписанный RS256 с данным ключом RSA, всегда не пройдет проверку PS256, и подпись может отличаться по длине на несколько байт. Убедитесь, что подписант и проверяющий используют один и тот же алгоритм. AWS SigV4 использует PS256, большинство OIDC IdP используют RS256. RSA-PSS также имеет параметр `saltLength` — OpenSSL по умолчанию 32, jose по умолчанию 32, `rsa.PSSOptions{SaltLength: rsa.PSSSaltLengthEqualsHash}` Go является правильным эквивалентом. Зафиксируйте это перед тестированием интеграции между языками.

Атака alg: none и атака подмены ключа HS256

Сервер выбирает алгоритм проверки на основе alg, объявленного в Header токена. Атакующий переписывает заголовок на `alg: none` (без подписи) или переписывает токен RS256 на HS256 (используя публичный ключ, как если бы он был общим секретным ключом HMAC) и обходит проверку. Исторические CVE, такие как CVE-2015-9235 (jsonwebtoken) и CVE-2022-23529 (множество Node-библиотек), восходят к этому шаблону. Сервер должен навязать белый список алгоритмов — например `algorithms: ['RS256']` — и никогда не позволять токену решать, какой алгоритм использовать. UI этого инструмента показывает как Header.alg, так и алгоритм, который вы действительно выбрали, и помечает несоответствия: это сама демонстрация в реальном времени 'клиент не должен доверять Header.alg'.