logo
GeekFormat

Decodificador, Verificador y Generador JWT

Encoded Token172 charsActualizado 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· Sujeto1234567890
name· NameJohn Doe
admin· Admintrue
iat· Emitido en151623902218/01/2018, 09:30:22
Header details2 items
algHS256HMAC (simétrico)
typ· TypeJWT
All operations run locally in your browser; the Token and key are never sent to any server.

Banco de trabajo JWT online gratuito: decodifica, verifica y genera JSON Web Tokens. Admite 13 algoritmos (HS256 / RS256 / ES256 / PS256 / EdDSA, etc.). Claves PEM y JWK. Generación automática de pares de claves. exp/iat/nbf analizados automáticamente. 100% del lado del cliente — el token nunca sale de tu navegador.

Relacionado

Casos de uso

  • Decodificar JWT online: divide rápidamente un token durante la depuración de inicio de sesión OAuth 2.0 / OIDC para inspeccionar el algoritmo del Header y los Claims del Payload
  • Verificar firmas JWT: usa un Secret / clave pública para validar firmas de tokens en tiempo real y decidir si un 401 es 'firma incorrecta', 'expirado' o 'discordancia de algoritmo'
  • Generar JWTs de prueba durante la integración: emite un JWT en el navegador con un par de claves de prueba, sin necesidad de pedir al backend que cambie temporalmente el código para emitir un token
  • Conversión PEM ↔ JWK: el IdP OIDC te dio JWK pero el servidor necesita PEM (o viceversa) — convierte en el lugar en lugar de escribir un script de OpenSSL
  • Diagnosticar 401 Unauthorized: recorre la expiración, la coincidencia de alg con la pasarela, la coincidencia de claves y el formato PEM uno por uno
  • Comparar RS256 vs PS256: muchos proveedores OIDC usan RS256 por defecto mientras que AWS SigV4 prefiere PS256 — cambia algoritmos con el mismo par de claves RSA y compara resultados
  • Aprender el funcionamiento interno de JWT: cambia el alg, edita el Payload, intercambia la clave en el navegador y observa cómo se rompe la firma en tiempo real — mucho más rápido que leer el RFC

Características

  • Decodificar + Verificar + Generar en un solo lugar: pega un token para separar Header/Payload/Signature, cambia algoritmo y clave para verificar la firma, edita Claims y vuelve a firmar para producir un nuevo token — cubre toda la cadena de solución de problemas JWT
  • 13 algoritmos compatibles: HS256/HS384/HS512 (HMAC), RS256/RS384/RS512 (RSA-PKCS1-v1_5), ES256/ES384/ES512 (ECDSA), PS256/PS384/PS512 (RSA-PSS), EdDSA — cubre OAuth 2.0, OIDC, JWS, pasarelas API y SSO empresarial
  • Formatos PEM y JWK: las claves RSA, ECDSA y Ed25519 aceptan cadenas PEM (con cabeceras -----BEGIN PUBLIC KEY-----) y JSON JWK (campos kid/kty/n/e) — pega directamente la salida de OIDC /.well-known/jwks.json
  • Múltiples formas de entrada para Secret HMAC: cadena UTF-8 sin procesar, bytes hexadecimales o Secret codificado en Base64/Base64URL — cambia con un clic, para que 'parece igual pero la firma falla' nunca suceda
  • Generación automática de pares de claves: pares de claves RSA-2048, RSA-4096, P-256, P-384 y Ed25519 generados en el navegador, presentados en formatos PEM y JWK para uso inmediato en pruebas
  • Resaltado semántico de Claims: exp / iat / nbf se convierten automáticamente a tiempo legible por humanos con estado expirado / aún no válido / emitido resaltado; alg / typ / kid en Header etiquetados individualmente
  • 100% del lado del cliente, cero subidas: cada análisis, verificación y firma se ejecuta a través de la API Web Crypto nativa del navegador — los tokens, claves y payload nunca salen del navegador, coincidiendo con el principio de seguridad de 'nunca pegar tokens de producción en herramientas online aleatorias'
  • Copiar con un clic: Header, Payload, Signature y el token recién generado son cada uno copiables independientemente para documentación, tickets y comandos curl

Cómo Usar

  1. Pega o escribe el token: suelta la cadena JWT en el cuadro de entrada; la herramienta separa automáticamente Header, Payload y Signature e imprime cada uno como JSON con formato
  2. Selecciona el algoritmo: cambia entre HS256 / RS256 / ES256 / PS256 / EdDSA; la herramienta infiere de Header.alg y marca cualquier discordancia
  3. Importa una clave: pega un Secret HMAC, una cadena PEM o un JSON JWK; para algoritmos asimétricos, haz clic en 'Generar par de claves' para obtener una clave de prueba inmediatamente
  4. Verifica o vuelve a firmar: en modo Decode verifica con una clave pública y ve '✅ firma válida / ❌ firma inválida'; en modo Encode edita Claims y firma con una clave privada para producir un nuevo token

Preguntas Frecuentes

¿Cuáles son las tres partes de un JWT?

Una cadena JWT se compone de tres segmentos `Header.Payload.Signature`, cada uno codificado en Base64URL. El Header declara el algoritmo (por ejemplo, HS256, RS256) y el tipo de token (typ: JWT); el Payload lleva los Claims del usuario, los campos comunes son sub (ID de usuario), iat (hora de emisión), exp (hora de expiración), nbf (no antes), aud (audiencia), iss (emisor); la Signature es el resultado de firmar los dos primeros segmentos con una clave, su propósito es 'detección de manipulación' no 'prevención de escuchas'.

¿Puedo editar el Payload después de decodificar un JWT?

Puedes verlo y editarlo, pero **no puedes falsificarlo**. Una vez que cambias el Header o el Payload, la Signature original se vuelve inválida inmediatamente y el servidor la rechazará. Para que el token modificado vuelva a ser usable, debes **volver a firmarlo** con el mismo algoritmo y la clave correcta — esta es la razón por la que esta herramienta proporciona 'decodificar + editar + generar' en un solo lugar: decodifica para echar un vistazo, edita lo que quieras y genera un nuevo token para pruebas inmediatamente, sin necesidad de pedir al backend que emita temporalmente.

¿Qué diferencia hay entre HS256, RS256, ES256, PS256 y EdDSA?

HS256 usa HMAC con un Secret compartido (simétrico), rápido pero requiere gestionar el Secret de forma segura; RS256 usa claves RSA privada/pública (asimétrico), adecuado para situaciones donde el firmante y el verificador están separados; PS256 usa relleno RSA-PSS, más seguro que RS256; ES256 usa curva elíptica P-256, firmas más cortas y mejor rendimiento; EdDSA (normalmente Ed25519) es muy rápido y determinista, recomendado para nuevos protocolos como OAuth 2.1.

¿Por qué mi JWT muestra firma inválida?

Las causas más comunes son que la clave, el formato del Secret, el algoritmo o la codificación Base64URL no coinciden exactamente. Un espacio adicional, un salto de línea PEM, confundir Base64 con Base64URL o que el servidor use RS256 mientras la herramienta usa HS256 hará que la verificación falle. Usa esta herramienta para cambiar algoritmos y formatos de Secret y probar uno por uno.

¿La misma clave RSA sirve para verificar RS256 y PS256?

No. RS256 y PS256 usan esquemas de relleno diferentes (PKCS1-v1_5 vs PSS). Aunque la clave RSA sea la misma, no pueden verificarse cruzadamente. El firmante y el verificador deben usar el mismo algoritmo.

¿Qué es un ataque alg:none?

Un atacante cambia el Header a `{"alg":"none"}` para decirle al servidor que no verifique la firma, o cambia RS256 a HS256 y usa la clave pública como Secret HMAC para engañar al servidor. El servidor debe usar una lista blanca de algoritmos (por ejemplo, `algorithms: ['RS256']`) y no debe confiar en el Header.alg del token para decidir el algoritmo de verificación.

¿Cómo convierto entre PEM y JWK?

PEM es el formato clásico de OpenSSL con líneas BEGIN/END, común en configuraciones heredadas; JWK es formato JSON, común en OAuth 2.0 / OIDC. Muchos IdP OIDC publican claves públicas en `/.well-known/jwks.json`. Esta herramienta admite ambos formatos y puede cambiar entre ellos.

¿El navegador puede verificar firmas JWT directamente?

Sí. La API Web Crypto admite HMAC, RSA, ECDSA, RSA-PSS y Ed25519 en navegadores modernos, por lo que esta herramienta puede verificar firmas directamente en el navegador sin subir el token.

¿Mi token se envía a un servidor?

No. El análisis, la verificación y la firma se realizan en el navegador. El panel Network no debería mostrar ninguna solicitud que contenga el token.

¿Puedo guardar datos sensibles en un JWT?

No. El Payload es legible por defecto (solo decodifica Base64URL). Contraseñas, documentos de identidad, números de tarjetas, claves API, Access Tokens o Refresh Tokens no deben colocarse en un JWT estándar. Si necesitas confidencialidad, considera JWE (JSON Web Encryption).

¿Qué es Decodificador, Verificador y Generador JWT?

JWT (JSON Web Token) es un estándar abierto definido por el IETF en RFC 7519 (RFC 7515 describe la forma de firma JWS, RFC 7516 describe el cifrado JWE, RFC 7517 define las claves JWK) para transferir de forma segura información de usuario 'afirmada' entre solicitudes HTTP, flujos OIDC y llamadas de microservicios. Una cadena JWT estándar se compone de tres segmentos codificados en Base64URL: Header (algoritmo y tipo), Payload (Claims, los datos del usuario) y Signature (una firma basada en clave sobre los dos primeros). Los tres segmentos se unen con un punto literal `.`, por ejemplo `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.

**JWT no es cifrado.** Este es el concepto erróneo más común. El Payload es texto plano por defecto — cualquiera puede decodificarlo con Base64URL y leer el contenido. JWT proporciona **detección de manipulación**, no confidencialidad: el servidor vuelve a firmar Header.Payload con la clave compartida y la compara con la Signature del token. Si coinciden, el token no ha sido alterado en tránsito. Esta es la metáfora del 'boleto de tren con un sello antifalsificación': al inspector le importa si el boleto es genuino, no si el código QR es ilegible.

JWT divide claramente las responsabilidades entre 13 algoritmos. **Familia HMAC** (HS256/HS384/HS512) usa una clave simétrica tanto para firmar como para verificar, rápida y simple, adecuada para un solo servicio o un clúster de confianza; el secret debe tener al menos la longitud del digest (por ejemplo, ≥ 32 bytes para HS256). **Familia RSA** (RS256/RS384/RS512) usa RSASSA-PKCS1-v1_5, el esquema asimétrico más común — los firmantes tienen la clave privada, los verificadores tienen la clave pública. **Familia RSA-PSS** (PS256/PS384/PS512) usa el relleno RSA-PSS más nuevo con garantías de seguridad más fuertes, preferido por AWS SigV4 y proveedores de identidad OIDC modernos. **Familia ECDSA** (ES256/ES384/ES512) usa curvas elípticas (P-256/P-384/P-521 respectivamente) con firmas más cortas y mejor rendimiento. **EdDSA** (principalmente Ed25519) es extremadamente rápido y determinista (mismo mensaje + misma clave = misma firma cada vez) y es el algoritmo recomendado en OAuth 2.1 y nuevos protocolos.

La seguridad es donde JWT tropieza en producción. La OWASP JWT Cheat Sheet destaca al menos cuatro reglas estrictas: (1) nunca pongas contraseñas, documentos de identidad, números de tarjetas o claves API como texto plano en el Payload; (2) el servidor **nunca debe confiar en el campo alg** declarado en el Header del Token — debe verificar con un algoritmo codificado, de lo contrario un atacante que reescriba el header a `alg: none` lo evade todo (esta es la raíz de CVEs históricos como CVE-2015-9235); (3) los secrets HMAC deben ser aleatorios y tener al menos 32 bytes, nunca cadenas cortas; (4) la verificación es más que verificar firmas — también debes validar `exp` (expiración), `nbf` (no antes), `iss` (emisor) y `aud` (audiencia). Esta herramienta resalta cada uno de estos Claims en la interfaz para que puedas decir de un vistazo si un fallo es un problema de firma, un problema de tiempo o un problema de Claims.

JWT no es un reemplazo para las sesiones. Las sesiones almacenan el estado del usuario en el servidor (Redis o una base de datos); JWT empaqueta el estado en el token. Las arquitecturas de microservicios, las API sin estado, los clientes móviles y las configuraciones con mucho CORS se benefician de JWT; los sistemas empresariales tradicionales y los flujos que requieren revocación instantánea (por ejemplo, 'expulsar a este usuario ahora') siguen siendo mejor atendidos por sesiones. Esta herramienta cubre tanto la depuración pura de JWT como los pasos de análisis de Token / verificación de firma / edición de Payload de una migración de sesión a JWT.

Code Examples

50 líneas de Node.js: firma y verificación HS256 escritas a mano

javascript

Destila el mecanismo central de JWT: codifica Header y Payload en Base64URL, luego aplica HMAC-SHA256 a la cadena `header.payload`. En producción, usa una biblioteca como jsonwebtoken o jose — este fragmento existe para hacer que los fallos de firma sean depurables.

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

Lado del navegador: API Web Crypto para firma HMAC

html

La idea central del front-end de esta herramienta: usa crypto.subtle nativo del navegador para verificación HMAC, RSA, ECDSA, RSA-PSS y Ed25519 — no se necesita biblioteca de terceros. Pega esto en cualquier página HTML para acuñar tokens HS256.

<!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: verifica RS256 con jose (la forma correcta)

javascript

Usa una biblioteca madura como jose, jsonwebtoken o PyJWT en producción — nunca escribas la tuya. Este fragmento muestra cómo jose verifica un token RS256, imprime el motivo del fallo en caso de error (discordancia de alg, firma incorrecta, expirado, kid no encontrado, 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'],     // crítico: la lista blanca de algoritmos bloquea ataques alg:none y sustitución HS256
    }
  )
  console.log('alg =', protectedHeader.alg)
  console.log('sub  =', payload.sub)
} catch (err) {
  console.error('verify failed:', err.code, err.message)
  // común: ERR_JWT_EXPIRED / ERR_JWS_INVALID / ERR_JWS_SIGNATURE_VERIFICATION_FAILED
}

Python: analiza un token e imprime sus Claims con PyJWT

python

La forma más común de depurar JWT en el lado de Python. decode() de PyJWT valida exp / nbf / iat por defecto y devuelve el resultado como un dict simple.

import jwt

token = 'eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxw'

# Analizar (sin verificación de firma, solo mira Header y Payload)
print(jwt.get_unverified_header(token))
# {'alg': 'HS256', 'typ': 'JWT'}

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

# Verificación completa
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/512UniversalAlgoritmo de clave simétrica. El mismo Secret firma y verifica, simple y rápido, adecuado para clústeres de servicios dentro de un límite de confianza. El Secret debe tener al menos 32 bytes aleatorios.
RS256 / RS384 / RS512RSASSA-PKCS1-v1_5 + SHA-2Web Crypto APIEl algoritmo asimétrico más común. Firma con la clave privada, verifica con la clave pública. Predeterminado para la mayoría de IdP OIDC, pasarelas API y SSO empresarial.
PS256 / PS384 / PS512RSA-PSS + SHA-2Web Crypto APIRSA-PSS es el reemplazo actualizado y más seguro de RS256. AWS SigV4, AWS Cognito y los proveedores OIDC modernos tienden a preferirlo. saltLength debe especificarse explícitamente.
ES256 / ES384 / ES512ECDSA + P-256/P-384/P-521Web Crypto APIFirmas de curva elíptica. Firmas cortas (ES256 son solo 64 bytes), rendimiento rápido, JWTs más pequeños. Apple Sign in with Apple usa ES256 por defecto.
EdDSA (Ed25519)Ed25519 / Ed448Web Crypto APIAlgoritmo de firma de alto rendimiento de próxima generación. Firmas deterministas (mismo mensaje + misma clave siempre producen el mismo resultado), sin riesgo de reutilización de nonce, recomendado por OAuth 2.1.

Output Example

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

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

Header decodificado:
  {
    "alg": "HS256",
    "typ": "JWT"
  }

Payload decodificado:
  {
    "sub": "1234567890",
    "name": "Jane Doe",
    "iat": 1716239022        // 2024-05-20 14:23:42 UTC
  }

Privacy & Security

Este banco de trabajo JWT se ejecuta 100% en tu navegador, respaldado por la API Web Crypto nativa del navegador. El token que pegas, el Header, el Payload, la Signature, el Secret HMAC, cualquier clave privada RSA/ECDSA, cualquier par de claves generado y cada cálculo de firma/verificación permanecen en tu dispositivo — nunca viajan a un servidor, nunca se registran, nunca se analizan y nunca se almacenan en caché. La página puede usarse sin conexión una vez cargada. Mejores prácticas: nunca pegues tokens de producción de larga duración o claves privadas de producción en ninguna herramienta online, incluida esta. Esta herramienta es apropiada para depuración, pruebas de integración, aprendizaje y acuñación de tokens de prueba — los secrets de producción y las claves privadas deben manejarse en un entorno controlado y local.

Authoritative References

Troubleshooting

Firma inválida: 'signature is invalid'

El token y la clave de verificación no coinciden. Las causas habituales: (1) la clave del servidor y la clave que pegaste en la herramienta son diferentes (lo más común); (2) la clave contiene caracteres invisibles (espacio al final, salto de línea, carácter de ancho cero); (3) se mezclan Base64 y Base64URL; (4) se selecciona el algoritmo incorrecto (Header dice HS256, el servidor verifica como RS256, o viceversa). Primero verifica que la clave coincida byte por byte: presta atención a los saltos de línea al final del PEM, los espacios al final del Secret HMAC y los valores `k` de JWK que pueden haber sido decodificados por URL incorrectamente. Confirma que el algoritmo en la herramienta coincide con el Header.alg del token. Usa la función de decodificar más verificar de esta herramienta para reproducir el error exacto y confirmar que ocurre entre 'decodificación exitosa' y 'verificación fallida'.

HTTP 401 Unauthorized: Token expirado o iat en el futuro

La verificación de firma pasó, pero `exp` está en el pasado (Token expirado), `nbf` aún está en el futuro (No antes), o `iat` es posterior a la hora actual del servidor (a menudo debido a desincronización de reloj). Otro caso común es un `aud` (audiencia) discordante: el token se emitió para la App A pero lo valida la App B. Usa el área de Claims resaltados de esta herramienta para detectar el estado de exp / nbf / iat de un vistazo. exp rojo = expirado, por favor reemite. nbf rojo = aún no válido, verifica si iat es una hora futura. aud rojo = audiencia incorrecta, verifica que el servidor tenga configurada la audiencia correcta.

Error de importación de PEM o JWK

PEM tiene líneas en blanco adicionales o le faltan marcadores de cabecera/pie (`-----BEGIN PUBLIC KEY-----`); a JWK le faltan campos requeridos (`kty` / `n` / `e` / `kid`); al valor `k` de JWK le falta el relleno Base64URL (debe estar rellenado con `=` o estrictamente sin `=`); se está importando una clave privada RSA como clave pública; se está suministrando una clave privada Ed25519 (semilla de 32 bytes) como 64 bytes. Reexporta un PEM PKIX estándar con `openssl rsa -in key.pem -pubout -outform PEM` o `openssl ec -in key.pem -pubout`; para JWK, usa la salida sin procesar del endpoint OIDC Discovery `/.well-known/jwks.json` en lugar de codificarlo a mano. Esta herramienta detecta automáticamente cabeceras PEM, relleno faltante y campos JWK faltantes y muestra una sugerencia.

Fallos de firma entre RS256 y PS256 entre lenguajes

RS256 usa RSASSA-PKCS1-v1_5, PS256 usa RSA-PSS. Los dos **no pueden verificarse cruzadamente** — un token firmado con RS256 por una clave RSA dada siempre fallará la verificación PS256, y la firma puede diferir en longitud en unos pocos bytes. Asegúrate de que el firmante y el verificador usen el mismo algoritmo. AWS SigV4 usa PS256, la mayoría de los IdP OIDC usan RS256. RSA-PSS también tiene un parámetro `saltLength` — OpenSSL usa 32 por defecto, jose usa 32, `rsa.PSSOptions{SaltLength: rsa.PSSSaltLengthEqualsHash}` de Go es el equivalente correcto. Bloquea esto antes de las pruebas de integración entre lenguajes.

Ataque alg:none y ataque de sustitución de clave HS256

El servidor elige un algoritmo de verificación basado en el alg declarado en el Header del token. Un atacante reescribe el header a `alg: none` (sin firma) o reescribe un token RS256 a HS256 (usando la clave pública como si fuera un Secret HMAC compartido) y evade la verificación. CVEs históricos como CVE-2015-9235 (jsonwebtoken) y CVE-2022-23529 (múltiples bibliotecas Node) se remontan a este patrón. El servidor debe aplicar una lista blanca de algoritmos — por ejemplo `algorithms: ['RS256']` — y nunca debe dejar que el token le diga al servidor qué algoritmo usar. La interfaz de esta herramienta muestra tanto Header.alg como el algoritmo que realmente seleccionaste, y marca las discordancias: eso es en sí mismo una demostración en vivo de 'el cliente no debe confiar en Header.alg'.