¿Es seguro pegar un JWT en un decodificador online?

Te topas con un error. Una petición falla con un 403 y la única pista es una cadena larga que empieza por eyJ. Quieres ver qué hay dentro, así que recurres al primer resultado de Google: un decodificador de JWT online. Pegas el token, lees el payload y sigues con lo tuyo.

¿Fue seguro? La respuesta honesta depende por completo de si el token estaba activo, y casi ningún decodificador te lo dice.

TL;DR: Decodificar un JWT es seguro. Los datos de dentro están codificados, no cifrados, así que leerlos no filtra nada nuevo. El riesgo está en el acto de enviar un token funcional a un servidor que no controlas, donde puede quedar registrado y reutilizarse. Nunca pegues tokens de producción en sitios que no sean tuyos.

Qué es realmente un JWT

Un JSON Web Token tiene tres partes unidas por puntos: header.payload.signature. Las dos primeras son JSON codificado en base64url. Base64url no es cifrado. Es un formato de texto reversible, la misma familia de codificación que se usa para meter datos binarios dentro de una URL. Cualquier ordenador puede convertirlo de nuevo en JSON legible en un milisegundo, sin clave y sin permiso.

Así que cuando un decodificador te muestra el payload, no ha descifrado nada. Ejecutó una transformación pública y determinista que tu navegador puede hacer por sí solo. El payload está ahí, a plena vista, dentro de cada petición que lleva el token. La codificación existe para que el dato sea seguro de transportar, no para ocultarlo.

Ese payload suele llevar claims como estos:

{
  "sub": "user_8842",
  "email": "[email protected]",
  "role": "admin",
  "exp": 1717459200
}

ID de usuario, email, rol y una marca de tiempo de caducidad. A veces más: IDs de inquilino, ámbitos de permisos, identificadores de sesión. Nada de esto es secreto para quien tiene el token, porque se supone que quien tiene el token eres tú. El navegador lo almacena, lo envía en cada petición y el servidor lee exactamente estos claims para decidir qué se te permite hacer.

La firma es la parte que importa

El tercer segmento es una firma criptográfica. El servidor que emitió el token la calculó usando una clave secreta (o una clave privada) que solo el servidor conoce. Cuando un token vuelve, el servidor recalcula la firma y comprueba que coincide. Si cambias un solo carácter del payload, la firma deja de ser válida y el servidor rechaza el token.

Esta es la parte que la gente entiende al revés. Un decodificador no verifica la firma. Solo divide la cadena y decodifica en base64 las dos primeras partes. Así que un decodificador te mostrará tan tranquilo un token manipulado, un token caducado o pura basura que ningún servidor aceptaría jamás. Ver un JSON con buena pinta en un decodificador no te dice nada sobre si el token funciona.

Y no puedes falsificar un token editando el payload decodificado. Subir tu role de user a admin y volver a codificar produce un token con una firma rota. Sin el secreto del servidor, no puedes generar una que coincida. Ese es justo el propósito de firmar.

Aquí está el truco. No necesitas falsificar nada si puedes robar un token que ya es válido. Un token activo y correctamente firmado es una credencial funcional. Quien lo tenga puede actuar como tú hasta que caduque. La firma protege contra la manipulación, no contra el robo.

Entonces, ¿dónde está el peligro real?

No está en decodificar. Está en la transmisión.

Cuando pegas un token en un decodificador online, estás confiando en que la herramienta lo decodifica localmente en tu navegador. Muchas no lo hacen. Un montón de estos sitios envían el token a su backend, lo decodifican en el servidor y te devuelven el resultado. Desde tu lado se ve idéntico. Aparece el payload, te quedas contento. Mientras tanto, el operador de ese sitio acaba de recibir una credencial totalmente funcional de tu cuenta.

Lo que pasa después se te escapa de las manos:

• El token puede quedar escrito en un log del servidor, a veces por accidente, a veces a propósito.
• Se puede reutilizar contra la API real. Si concede acceso de administrador, la copia también lo concede.
• Sigue siendo válido hasta que pasa el momento de exp. Los tokens de vida corta limitan el radio de daño a unos minutos. Los de vida larga le dan al atacante horas o días.
• Algunos tokens nunca caducan. Algunos son refresh tokens, que pueden generar nuevos access tokens a demanda. Pegar uno de esos en el servidor de un desconocido es casi como entregarle la cuenta de forma permanente.

Probablemente nunca llegues a enterarte de que ocurrió. No hay aviso de brecha por una credencial que entregaste voluntariamente. La decodificación se vio normal, el error se arregló y una copia de tu sesión está en los logs de otra persona.

Esto no es paranoia hacia un sitio malicioso concreto. Es la estructura de la situación. No puedes saber desde fuera si un decodificador determinado es honesto, y la consecuencia, si no lo es, es que te roben la cuenta. Cuando el coste de equivocarse es tan alto, lo razonable por defecto es asumir que el token salió de tu máquina.

Cómo decodificar sin riesgo

Unos pocos hábitos hacen que esto deje de ser un problema.

Usa un token que no importe. Si solo necesitas entender la estructura de los JWT o comprobar qué claims pone tu proveedor de autenticación, genera un token de ejemplo. Parece real y se decodifica igual, pero no apunta a ninguna cuenta real, así que da igual quién lo vea.

Usa un token caducado. Si estás depurando la sesión de un usuario concreto, una copia caducada te sigue mostrando los mismos claims y no se puede reutilizar para obtener acceso. Saca uno de los logs de ayer en lugar de la petición en vivo.

Nunca pegues tokens de producción o activos en un sitio que no controles. Esta es la única regla que lo cubre todo. Si el token funciona ahora mismo contra un sistema real, trátalo como una contraseña, porque en la práctica lo es.

Decodifícalo tú mismo cuando puedas. Tu propia máquina puede hacer esto sin ninguna web. En la línea de comandos:

# split on dots, base64-decode the payload (second field)
echo "$JWT" | cut -d. -f2 | base64 -d 2>/dev/null

Eso nunca toca la red. El token no sale de tu portátil.

Cómo verificar que un decodificador es del lado del cliente

Si aun así quieres una herramienta de navegador por comodidad, confirma que de verdad mantiene el token en local antes de confiarle algo sensible.

La prueba offline es la demostración más sencilla. Carga la página y luego desconéctate de internet (apaga el Wi-Fi o desenchufa el cable). Pega un token. Si sigue decodificando, el trabajo está ocurriendo en tu navegador, porque no hay ningún servidor al que llegar.

La prueba con la pestaña de Red es más precisa. Abre las herramientas de desarrollo de tu navegador, ve a la pestaña de Red, límpiala y pega un token en la herramienta. Observa la lista de peticiones. Un decodificador genuino del lado del cliente no produce ninguna petición saliente nueva que lleve tu token. Si ves que se dispara una petición en el momento en que pegas, el token va a alguna parte, y deberías asumir que esa parte ahora lo tiene.

Cualquiera de las dos pruebas lleva menos de un minuto y zanja la cuestión para siempre. Una herramienta que pasa ambas es una en la que puedes pegar sin pensarlo, porque nada de lo que escribes cruza nunca la red.

Estamos construyendo un decodificador de JWT para dev.hivly.net que se ejecuta por completo en el navegador, de modo que los tokens se decodifican en tu propia máquina y nunca se transmiten a ningún sitio. Llegará pronto. Hasta entonces, las comprobaciones offline y de la pestaña de Red de arriba te permiten revisar cualquier decodificador que ya uses.

La versión corta: decodificar es inofensivo, los datos no son secretos y no puedes falsificar un token editándolo. Lo único que puede hacerte daño es entregar una credencial activa y funcional a un servidor que no controlas. Mantén los tokens activos en máquinas tuyas, haz pruebas con tokens caducados o de ejemplo y verifica que tu decodificador se ejecuta en local. Haz eso y la pregunta de si es seguro deja de ser una pregunta.