Decodificador JWT
Lea el encabezado y las afirmaciones de un token y vea lo que dice sobre sí mismo. Decodificación, no verificación.
Descodificar no es verificar. Los dos segmentos legibles de un JWT son solo Base64: cualquiera puede leerlos y cualquiera puede escribirlos. Lo único que hace fiable a un token es la firma, y comprobarla exige la clave. Esta página no tiene la clave, no te la pide y no afirma nada sobre si el token es auténtico.
El prefijo «Bearer» se elimina automáticamente. Nada de lo que pegues sale de esta página.
Tres segmentos, y solo uno importa
Un JWT son tres cadenas en base64url unidas por puntos. Las dos primeras son JSON que puedes leer; la tercera es una firma sobre esas dos.
eyJhbGciOiJIUzI1NiJ9 . eyJzdWIiOiIxMjM0In0 . 4fXK...
header payload signatureLa cabecera dice qué algoritmo lo firmó. El contenido lleva los claims. Ninguno de los dos está cifrado: el base64 es codificación de transporte, no ocultación, y cualquiera que tenga el token puede leer ambos en cosa de un segundo.
La firma es la única parte que hace trabajo de seguridad. Demuestra que los dos primeros segmentos los produjo alguien con la clave de firma y que no se han modificado desde entonces. Sin comprobarla, un JWT es un archivo de texto que se describe a sí mismo y no tiene más autoridad que cualquier otra cadena que te haya enviado un cliente.
Por eso esta página no te va a decir que un token es válido
Verificar exige la clave, y no existe ninguna versión de «pega tu secreto de firma en una página web» que sea un buen consejo. Lo que hace la herramienta en su lugar es contarte lo que el token dice de sí mismo: si ha caducado, si ya ha llegado su hora de entrada en vigor, si el algoritmo es simétrico o asimétrico, y si afirma no necesitar ninguna firma.
alg:none, y por qué resulta instructivo
La especificación permite "alg": "none": un token sin firma. El ataque se escribe solo: coge un token legítimo, edita el contenido para afirmar lo que te apetezca, pon el algoritmo en none, borra la firma y envíalo.
Una biblioteca que lea el algoritmo de la cabecera y haga lo que esta dice aceptará eso. El atacante ha elegido la política de verificación, porque la política estaba en la parte del mensaje que controla el atacante.
La variante relacionada es la confusión de algoritmos. Un servidor que verifica RS256 tiene la clave pública, que no es secreta. Cambia la cabecera a HS256 —un algoritmo simétrico— y firma usando esa clave pública como secreto compartido. Una biblioteca ingenua usa el mismo material de clave para ambos casos y el token falsificado se verifica.
Los dos se arreglan igual, y es un principio general que conviene llevarse a otros sitios: quien verifica debe declarar qué algoritmos acepta, en vez de preguntárselo al token.
Qué se tuerce de verdad en producción
| Síntoma | Causa habitual |
|---|---|
| Se rechaza justo después de emitirlo | Desfase de reloj. El iat o el nbf van unos segundos por delante del reloj de quien verifica. Deja una pequeña tolerancia. |
| Funciona en local, falla desplegado | Distinta clave de firma por entorno: un token de preproducción enviado a producción. |
| Firma válida y aun así se rechaza | El claim aud o iss no coincide con lo que ese servicio espera. |
| Funciona y luego deja de hacerlo a mitad de sesión | Caducidad. Los tokens de vida corta necesitan un flujo de renovación, y suele ser la pieza que falta. |
| Las peticiones fallan con cabeceras demasiado grandes | El token ha crecido por encima del límite. La mayoría de los servidores topan las cabeceras en torno a 8 KB, y los navegadores topan una cookie en 4 KB. |
El problema de la revocación
El motivo para usar un JWT es que verificarlo no exige consultar ninguna base de datos: el token lleva su propia prueba. Y eso es justamente por lo que no puedes revocarlo. En el momento de verificar no se consulta nada, así que no hay dónde anotar que un token debería dejar de funcionar.
Las opciones, ninguna gratis:
- Caducidad corta más tokens de renovación. La respuesta estándar. Los tokens de acceso viven minutos; los de renovación se comprueban contra una base de datos y se pueden revocar.
- Una lista de denegación. Comprobar el
jtide cada token contra un almacén de revocados, lo cual reintroduce justo la consulta que el formato existía para evitar. - Rotar la clave de firma. Invalida todos los tokens de golpe, incluidos los de todo el mundo.
Si necesitas más la revocación inmediata de sesiones concretas que la verificación sin estado, un identificador de sesión opaco respaldado por un almacén es el diseño más sencillo, y está infravalorado.
Relacionado
Los tres segmentos son Base64 seguro para URL, sin relleno, y por eso un segmento falla a menudo en un descodificador estricto. Una vez descodificadas, las dos partes legibles son JSON. Y para la credencial a la que el token sustituye, el comprobador de fortaleza cubre el otro extremo del inicio de sesión.
Preguntas sobre JWT
¿La decodificación de un JWT lo verifica?
No, y la distinción es todo el modelo de seguridad. El encabezado y la carga útil son base64url; leerlos no requiere nada. La verificación significa volver a calcular la firma con la clave y compararla, lo que demuestra que el token fue emitido por quien posee esa clave y no ha sido alterado desde entonces. Un decodificador sin la clave puede decirle lo que afirma un token; sólo la verificación te dice si creerlo.
¿Es seguro pegar un token real en un sitio web?
En esta página, sí: la decodificación se realiza en su navegador y no se transmite nada. Pero el instinto detrás de la pregunta es bueno y vale la pena conservarlo. Un JWT suele ser una credencial activa: cualquiera que la posea puede actuar como usted hasta que caduque. Se ha entregado una sesión de trabajo a un decodificador que lo envía a un servidor. Compruebe dónde funciona cualquier herramienta antes de pegarle un token de producción.
¿Puedo poner secretos en una carga útil JWT?
No. La carga útil está firmada, no cifrada; cualquier persona que tenga el token, incluido el usuario al que se emitió, puede leerla. La firma garantiza que el contenido no ha sido modificado; no hace nada para ocultarlos. Si realmente necesita una carga útil confidencial, esa es JWE, una especificación diferente y considerablemente más complicada. En la práctica, la mejor respuesta suele ser mantener la parte sensible en el servidor y poner un identificador en el token.
¿Cuál es la vulnerabilidad alg:none?
La especificación JWT permite un "alg" de "none", es decir, un token sin firmar. El ataque consiste en tomar un token válido, cambiar la carga útil para reclamar administrador, establecer alg en ninguno y eliminar la firma. Una biblioteca que confíe en el campo del algoritmo del encabezado lo validará; el propio token especifica que no se requiere verificación. Todas las bibliotecas importantes han sido parcheadas, pero la lección es general: el servidor debe decidir qué algoritmos acepta, en lugar de dejar que el token nomine uno.
¿Cómo revoco un JWT antes de que caduque?
En gran medida no se puede, y este es el intercambio que realiza el formato. Un JWT es verificable sin una búsqueda en la base de datos, lo que lo hace rápido, y también es la razón por la que nada de lo consultado en el momento de la verificación sabe que deseaba revocarlo. Las respuestas viables son tiempos de vencimiento cortos con tokens de actualización, una lista de identificadores revocados verificados en cada solicitud (que reintroduce la búsqueda que estaba evitando) o rotar la clave de firma para invalidar todo a la vez.
¿Por qué se rechaza mi token cuando parece válido?
Después del vencimiento, las causas habituales son un desfase del reloj entre el emisor y el verificador, una audiencia o reclamo del emisor que no coincide con lo que espera el servidor, o que el token haya sido firmado con una clave diferente a la que posee el verificador (comúnmente un token provisional utilizado contra la producción). El decodificador de arriba señala los problemas de sincronización que puede ver; la audiencia y las discrepancias de claves sólo el servidor puede informarle.
Última revisión . ¿Has visto algo desactualizado? Dínoslo.