Firmante y verificador de JWT

Firma un token con tu propia clave, verifícalo con un secreto, una PEM, una JWK o una JWKS en vivo — y crea el conjunto de claves que publica tu API. Toda la criptografía se ejecuta en tu navegador.

Un JWT solo es tan fiable como su firma. Cualquiera puede leer un token: decodificar no prueba nada, así que esta herramienta hace la parte que un decodificador no puede: firma tokens con tu clave (HS256/384/512, RS256/384/512, ES256/384/512, EdDSA), los verifica con un secreto, una clave pública PEM o JWK, una JWKS pegada o una URL de JWKS en vivo con correspondencia de kid, y crea la JWKS que publica tu propia API. La guía complementaria firmar y verificar JWT explica por qué decodificar no es verificar, cómo funciona el ataque de confusión de algoritmos y qué demuestra — y qué no demuestra — un «verificado». Para leer un token sin clave, usa el decodificador JWT; para las claves en sí, la SSH Key Suite cubre la generación y la conversión.

Última actualización:

Firmar un token

🔒 La firma y la verificación se hacen localmente con WebCrypto. Los secretos y las claves privadas nunca se envían, se almacenan ni se registran — recarga la página y desaparecen.

Tus claves nunca salen de esta página

La firma y la verificación usan WebCrypto, el módulo criptográfico de tu navegador, con las claves que pegues o generes aquí. Los secretos y las claves privadas viven solo en la memoria de la página: no se suben, no se escriben en localStorage ni en cookies y nunca aparecen en la URL. Recarga o cierra la página y desaparecen. La única excepción es la descarga de una URL de JWKS, que inicias tú mismo: solo envía la URL que escribiste, para obtener claves públicas — nunca un secreto. Lee firmar y verificar JWT antes de pegar una clave de producción en ningún sitio.

Los límites honestos

EdDSA necesita un navegador actual: WebCrypto Ed25519 no existe en navegadores antiguos, y esta página lo dice claramente en lugar de fingir una firma. ECDSA P-256 se ofrece como la alternativa que funciona en todas partes.

Las PEM cifradas (una clave privada protegida con contraseña) no son compatibles en la versión 1. La página las rechaza abiertamente: descífrala primero con openssl pkcs8 -topk8 -nocrypt y nunca pegues una contraseña en una página web.

La descarga de una URL de JWKS depende de que ese servidor envíe cabeceras CORS. Muchos proveedores de identidad lo hacen; cuando uno no lo hace, la descarga falla honestamente y la página te dice que pegues la JWKS. Solo se descargan claves públicas: una URL de JWKS nunca lleva un secreto.

Cuando firmar supera a decodificar

Decodificar un JWT es leerlo: la cabecera y la carga útil son base64url, y cualquiera que tenga el token puede ver ambas. Por eso un decodificador por sí solo nunca puede responder a la única pregunta que importa: ¿firmó realmente esto el emisor? Firmar es la otra mitad del trabajo: quien tiene la clave privada (o el secreto HMAC) produce la firma, y la verificación repite las mismas matemáticas con la clave pública. Esta página mantiene ambas mitades en tu navegador, porque las claves implicadas son los datos más sensibles que jamás maneja una herramienta web.

La diferencia importa sobre todo con los algoritmos asimétricos. Con HS256, el secreto que verifica es el mismo secreto que firma: cualquiera que pueda comprobar tus tokens también puede crearlos, lo que está bien dentro de un solo servicio y es una filtración en cualquier otro sitio. Con RS256, ES256 o EdDSA, la clave de firma se queda con el emisor y solo viaja la clave pública: tu API puede publicar su JWKS, rotar claves añadiendo un nuevo kid y dejar que cualquier verificador del mundo compruebe tokens sin tener jamás el poder de falsificar uno.

Lo que la herramienta se niega a hacer

Dos negativas son deliberadas. La primera es alg: none: un token que dice no necesitar firma se rechaza de plano, con el motivo a la vista: un verificador que lo acepta acepta falsificaciones. La segunda es la confusión de algoritmos: un token RS256 ofrecido con un secreto HMAC (o al revés) falla con una advertencia explícita, nunca reinterpretando la clave en silencio en la otra familia. Ambos son ataques clásicos contra JWT, y ambos se bloquean por estructura aquí: la familia de la clave debe coincidir con la familia del alg del token, o la verificación falla.

La tercera negativa es más sutil: esta página nunca te dice que un token es «de confianza». Una firma válida demuestra que el token se firmó con una clave, y la comprobación de caducidad demuestra que está dentro de su ventana: nada más. Que esa clave sea de fiar es una decisión sobre de dónde viene: una JWKS descargada de la URL conocida de tu proveedor de identidad, una clave pública que fijaste tú mismo, un secreto que generaste. La guía firmar y verificar JWT explica qué demuestra — y qué no demuestra — un «verificado».

Términos JWT, fijados

JWT. JSON Web Token (RFC 7519): una forma compacta y segura para URL de transportar claims entre partes: cabecera.carga útil.firma, cada una codificada en base64url. La carga útil la puede leer cualquiera; solo la firma depende de un secreto.

JWS. JSON Web Signature (RFC 7515): el formato de firma que hay debajo de los JWT. Un JWT es un JWS cuya carga útil es un conjunto de claims JSON.

JWK. JSON Web Key (RFC 7517): un objeto JSON que representa una clave criptográfica: kty, y el material de la clave (n/e para RSA, x/y para EC, x para Ed25519, k para un secreto compartido).

JWKS. JSON Web Key Set: un objeto con un array "keys"; la forma estándar en que un emisor publica sus claves públicas, normalmente en /.well-known/jwks.json.

kid. Key ID: el claim de la cabecera que dice qué clave firmó un token. Un verificador lo compara con la JWKS; sin él, se usa el conjunto de una sola clave y la página lo dice.

alg. El claim de la cabecera que nombra el algoritmo de firma (HS256, RS256, ES256, EdDSA…). Un verificador debe fijar los algoritmos que acepta: fiarse del propio claim alg del token es el ataque de confusión.

HMAC. Hash-based Message Authentication Code: una firma simétrica: el mismo secreto firma y verifica. Rápido y sencillo; cualquiera que tenga el secreto puede crear tokens.

RSASSA-PKCS1-v1_5. El esquema de firma RSA que hay detrás de RS256/384/512: el hash se envuelve y se eleva al exponente privado. Determinista: la misma entrada produce siempre los mismos bytes de firma.

EdDSA. Edwards-curve Digital Signature Algorithm: Ed25519 aquí: claves pequeñas, verificación rápida, firmas deterministas. Necesita un navegador actual para el soporte de WebCrypto.

Preguntas frecuentes

¿Es seguro pegar una clave privada en esta página?

En esta página la clave nunca sale de tu navegador: la firma se ejecuta en la memoria de la página con WebCrypto, nada se sube, se almacena ni se registra, y una recarga la borra. El patrón inseguro es un firmante en el servidor, donde tu clave privada cruza la red. Incluso en local, usa un dispositivo en el que confíes, y trata una clave de producción pegada como expuesta si la máquina es compartida. Genera aquí claves de prueba en lugar de pegar las reales.

¿Por qué mi token RS256 no se verifica con mi secreto?

Porque un secreto y una clave RSA son familias distintas, y la página se niega a mezclarlas: esa negativa es la protección contra la confusión de algoritmos. Un token RS256 necesita la clave pública RSA del emisor (PEM, JWK o JWKS); un secreto solo puede verificar HS256/384/512. Si tienes la clave pública en el formato equivocado, conviértela: la pestaña JWKS convierte PEM ⇄ JWK.

¿Qué envía realmente la descarga de una URL de JWKS?

Una petición GET a la URL que escribiste, pidiendo JSON. No va con ella ninguna clave, ningún secreto, ningún token ni ningún identificador: la respuesta es un conjunto de claves públicas. Si el servidor no envía cabeceras CORS, el navegador bloquea la lectura y la página te dice que pegues la JWKS.

Mi token se verifica aquí, pero la API lo rechaza. ¿Por qué?

La verificación aquí comprueba la firma y la ventana de tiempo con la clave que diste. Una API comprueba además los claims: el emisor (iss) que espera, la audiencia (aud) a la que sirve y si el id de clave (kid) es uno en el que confía ahora mismo. Un token firmado con una clave ya rotada, o creado para otra audiencia, se verifica matemáticamente y aun así se rechaza, correctamente.

EdDSA no funciona en mi navegador. ¿Qué hago?

Ed25519 necesita un navegador actual: los antiguos carecen por completo de Ed25519 en WebCrypto, y esta página lo dice en lugar de fingirlo. Usa ES256 (ECDSA P-256) como alternativa: es compatible en todos los sitios donde existe WebCrypto, y la página puede generar la clave por ti. Si debes usar Ed25519, actualiza el navegador.