Ir al contenido principal
Bethemesh
Seguridad y privacidad

Verificador de firma JWT

Valida un JSON Web Token: firma HS256/384/512 con el secreto compartido, RS, PS o ES 256/384/512 con una clave pública JWK, JWKS (elegida por kid) o PEM, y después comprobación de fechas con tolerancia de reloj, del emisor y de la audiencia esperados.

  • Portapapeles

Integrar este widget

Personaliza el aspecto, comprueba la vista previa y copia el código.

Vista previa

Tipo de código de integración

Código para copiar

Se adapta a tu página y Bethemesh ajusta su tamaño automáticamente.

HS256, HS384, HS512: el secreto compartido. RS, PS y ES: la clave pública en JWK, en JWKS (elegida por kid) o en PEM «BEGIN PUBLIC KEY».

Comprobaciones opcionales

Fija el algoritmo para una validación similar a producción. El modo automático sirve sobre todo para inspeccionar.

¿Te ha resultado útil esta herramienta?

¿Cómo funciona esta herramienta?

El verificador JWT te dice si un token es auténtico y sigue siendo aceptable: comprueba su firma criptográfica y después sus claims. Está pensado para desarrolladores back-end, integradores OAuth/OpenID Connect y equipos de seguridad que quieren confirmar que un token lo firmó la clave correcta antes de buscar el fallo en otro sitio. Para leer simplemente el contenido de un token, basta con el decodificador JWT.

La firma de un JWS (RFC 7515) se calcula sobre la cadena «cabecera.payload» en Base64URL; los algoritmos los define la RFC 7518. Para HS256, HS384 y HS512, la herramienta recalcula un HMAC con el secreto compartido y lo compara con la firma. Para RS256/384/512 (RSASSA-PKCS1-v1_5), PS256/384/512 (RSASSA-PSS) y ES256/384/512 (ECDSA sobre P-256, P-384 y P-521), verifica la firma con la clave pública mediante la Web Crypto API; en ECDSA la firma JWS es la concatenación directa R‖S, 64 bytes para ES256, y no una estructura DER. Un token que declara alg: none se rechaza siempre.

La clave pública puede darse de tres formas: una JWK sola (RFC 7517), un JWKS {"keys":[…]} en el que la herramienta elige la clave cuyo kid coincide con el de la cabecera, o un PEM «BEGIN PUBLIC KEY» (SubjectPublicKeyInfo). Para una validación similar a producción, selecciona un Algoritmo esperado en lugar de dejar el modo Automático: así el token no puede imponer otro algoritmo admitido mediante su propio campo alg. El modo Automático sigue siendo útil para inspeccionar. Una vez validada la firma, comprueba exp y nbf con una tolerancia de reloj ajustable (por ejemplo 60 segundos para absorber el desfase entre servidores) y, si los indicas, el emisor iss y la audiencia aud esperados. El resultado muestra «válido» o «no válido» con el motivo exacto: firma incorrecta, kid no encontrado, token expirado, todavía no válido, emisor o audiencia inesperados.

Cómo utilizar esta herramienta

  1. Pega el JWT

    Pega el token completo. El algoritmo declarado en la cabecera determina el tipo de clave esperado: secreto para HS*, clave pública para RS*, PS* y ES*.

  2. Aporta la clave

    Escribe el secreto compartido o pega una clave pública JWK, un JWKS completo o un PEM PUBLIC KEY. Con un JWKS, la clave se elige automáticamente por su kid.

  3. Ajusta los controles y lee el veredicto

    Ajusta la tolerancia de reloj, añade si hace falta el emisor y la audiencia esperados, y lee el resultado válido o no válido con su motivo.

Casos de uso

Verificar un token de Auth0, Keycloak o Entra ID

Descarga el JWKS publicado en el jwks_uri de tu proveedor (por ejemplo /.well-known/jwks.json), pégalo junto al token y confirma que la firma RS256 corresponde a una clave publicada.

Depurar una rotación de claves

Tras una rotación, tu API rechaza tokens: comprueba si el kid de la cabecera sigue existiendo en el JWKS o si el token se firmó con una clave retirada.

Comprobar un secreto HS256 entre dos servicios

Un microservicio rechaza los tokens que emite otro: prueba el secreto compartido y la audiencia esperada para saber si el problema está en la clave o en los claims.

Ejemplos

Inspecciona un JWT de prueba

Entrada

Token JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c; Algoritmo esperado: HS256; Secreto o clave pública: clave-incorrecta

Resultado

Token rechazado: Firma no válida: el token se modificó o la clave no corresponde. Datos del token: sub=1234567890 e iat=1516239022, sin campo exp.

Consejos y buenas prácticas

  • Si solo tienes un certificado (BEGIN CERTIFICATE), extrae antes su clave pública, por ejemplo con openssl x509 -pubkey -noout, porque la herramienta espera un PEM PUBLIC KEY.
  • Un secreto HS256 que un proveedor entrega en Base64 debe usarse con exactamente los mismos bytes que sirvieron para firmar: la cadena Base64 y su versión decodificada no dan la misma firma.
  • Mantén una tolerancia de reloj corta (de decenas de segundos a pocos minutos): un valor demasiado amplio equivale a aceptar tokens expirados.

Fuentes y referencias

Preguntas frecuentes

¿Qué diferencia hay entre decodificar y verificar un JWT?

Decodificar es leer la cabecera y el payload codificados en Base64URL, sin ninguna clave. Verificar es recalcular o comprobar la firma con el secreto o la clave pública del emisor y después validar exp, nbf, iss y aud. Solo la verificación demuestra que el token no se ha falsificado ni modificado.

¿Qué clave necesito para verificar un JWT RS256 o HS256?

HS256 es simétrico: el mismo secreto firma y verifica. RS256, PS256 y ES256 son asimétricos: el emisor firma con su clave privada y tú verificas con la clave pública, normalmente publicada en un JWKS. Nunca necesitas la clave privada para verificar.

¿Para qué sirve el kid en la cabecera de un JWT?

El kid (key ID) indica qué clave del JWKS firmó el token, lo que permite al emisor publicar varias claves durante una rotación. Cuando pegas un JWKS, la herramienta selecciona la clave cuyo kid coincide. Si ninguno coincide, probablemente la clave se ha retirado o el JWKS no es del emisor correcto.

¿Por qué la firma de mi JWT no es válida?

Las causas más habituales son una clave equivocada (otro entorno, una clave retirada), un secreto mal codificado, un token modificado o cortado, o una clave que no corresponde al algoritmo declarado. En el servidor, impón siempre el algoritmo esperado en lugar de fiarte del campo alg, para evitar los ataques de confusión de algoritmo descritos en la RFC 8725.

¿Qué es la tolerancia de reloj (leeway)?

Es un margen que se añade al comprobar exp y nbf para compensar una pequeña diferencia entre el reloj del emisor y el del verificador. Con 60 segundos de tolerancia, un token que expiró hace 30 segundos se sigue aceptando. La mayoría de las bibliotecas usan un valor de entre 0 y 5 minutos.

¿Puedo pegar una clave o un secreto en esta herramienta?

Una clave pública no es secreta y puedes pegarla sin riesgo. Un secreto HMAC sí lo es: aquí la verificación se ejecuta en tu navegador con la Web Crypto API y no se transmite nada, pero evita igualmente usar un secreto de producción en un equipo compartido.

Workflow recomendado

Continúa tu proceso

Descubre herramientas que encajan antes, después o como complemento de esta.

Usar antes

Decodificador JWT

Decodifica un JWT para leer su cabecera, su payload, sus claims y sus fechas de expiración.

Seguridad y privacidadDestacadaUsar esta herramienta

Funciona bien con

Inspector JWK / JWKS

Analiza una clave JWK o un JWKS: kid, kty, alg, use, huella RFC 7638 y aviso si se expone una clave privada.

Seguridad y privacidadUsar esta herramienta

Codificador JWT

Crea y firma un JWT HS256, HS384 o HS512 a partir de una cabecera, un payload JSON y un secreto.

Seguridad y privacidadUsar esta herramienta

También te puede interesar