Decodificador de JWT

Qué lleva dentro un token

Un JWT son tres partes separadas por puntos. Las dos primeras son JSON codificado en Base64url que cualquiera puede leer; la tercera es la firma.

• Cabecera — el algoritmo de firma (alg) y el tipo (typ). Los servicios que rotan claves añaden un kid que señala cuál se usó.
• Payload — las reclamaciones. sub identifica al usuario, iss al emisor, aud al destinatario previsto, y exp, iat y nbf llevan tiempos.
• Firma — las dos primeras partes firmadas con una clave.

La especificación define las reclamaciones de tiempo como enteros en segundos. Un token que puso milisegundos ahí aparece aquí a miles de años en el futuro, lo que delata un fallo en quien lo emitió.

Decodificar no es verificar

Que aquí se lea el contenido no dice nada sobre si el token es auténtico. El payload no está cerrado con llave, cualquiera puede reescribirlo, y solo quien tiene la clave nota que la firma ya no cuadra.

Por eso el servidor debe verificar la firma en cada petición, y al hacerlo no puede fiarse del campo alg. Fija el algoritmo esperado en el servidor y rechaza cualquier token que diga none o que no coincida con lo previsto. Las implementaciones que siguen la cabecera a ciegas son la vía clásica por la que se cuelan tokens sin firmar.

Nada de secretos en el payload

Cualquiera con el token, incluido quien abra las herramientas del navegador, lee el payload. Si ahí van un número de identidad, una nota interna de administración o datos de pago, dalos por publicados.

Ahí solo cabe lo que no te importe que vea el portador: un identificador de usuario, nombres de rol, una caducidad. El resto se queda en el servidor y se consulta cuando hace falta.

Antes de pegar el token de otra persona

Esta herramienta no envía el token a ninguna parte. Aun así, un token vigente es una credencial: si lo pegas en un chat o en un gestor de incidencias, quien lo lea puede usarlo. Si se te escapa uno, revoca esa sesión en lugar de esperar a que caduque.