Decodificador de JWT

Un JSON Web Token son tres bloques de texto separados por puntos: cabecera, contenido y firma. Los dos primeros son JSON escrito en Base64url, y eso significa que su interior está a la vista de cualquiera que tenga el token. Base64 no es cifrado: es una forma de escribir bytes con caracteres seguros para viajar por una URL o una cabecera HTTP.

De ahí sale la confusión que más caro se paga con esta tecnología. Un JWT va firmado, no cerrado. La firma garantiza que nadie ha cambiado lo que hay dentro sin conocer la clave, pero no impide leerlo. Poner el DNI de un cliente, un teléfono o un rol interno en el contenido equivale a publicarlo: quien reciba el token lo lee sin saber ningún secreto.

La otra distinción importante es entre descodificar y verificar. Descodificar es lo que hace esta página: separar los bloques y enseñar lo que llevan. No demuestra absolutamente nada, porque un token falsificado se descodifica igual de bien que uno legítimo. Verificar es recalcular la firma con la clave y comprobar que sale la misma, y es lo único que autoriza a fiarse del contenido.

El token se parte por los puntos. La cabecera dice con qué algoritmo se firmó —el campo «alg»— y a veces con qué clave, en «kid». El contenido lleva las afirmaciones sobre quién es el portador y hasta cuándo vale. La firma es el resultado de aplicar el algoritmo a los dos primeros bloques tal cual viajan, sin descodificar.

Las fechas de un JWT no son las de JavaScript. El estándar las llama NumericDate y las cuenta en segundos desde el 1 de enero de 1970, mientras que un Date de JavaScript cuenta milisegundos. Confundirlos produce fechas del año 56000 en lugar de un error visible, y es el motivo por el que un token parece no caducar nunca.

Con HS256, HS384 y HS512 la firma es un HMAC: un resumen calculado con una clave secreta que conocen tanto el que emite como el que valida. Comprobarla solo requiere ese secreto, así que esta herramienta puede hacerlo entera dentro del navegador.

Con RS, PS, ES y Ed el esquema cambia: se firma con una clave privada y se comprueba con la pública correspondiente. Nadie salvo el emisor puede generar tokens, y cualquiera con la clave pública puede validarlos. Aquí se reconocen y se identifican, pero no se verifican, porque haría falta la clave pública del emisor y no un secreto compartido.

El RFC 7519 reserva siete nombres. Todos son opcionales, y cada emisor añade además los suyos: un rol, un identificador de organización, un correo. Los reservados son los que cualquier biblioteca sabe interpretar sin que se lo expliquen.

El estándar admite el valor «none» en el campo «alg», pensado para casos donde la integridad ya está garantizada por otra capa. Un atacante puede aprovecharlo: coge un token legítimo, le cambia el contenido, pone «alg» a «none» y borra la firma.

Si la biblioteca del servidor decide cómo validar leyendo el propio token, aceptará ese token sin firma y el atacante entrará como quien quiera. La defensa es no preguntarle al token: el servidor debe fijar de antemano qué algoritmo espera y rechazar cualquier otro, incluido un HS256 donde esperaba un RS256.

Como el contenido se lee sin clave, no cabe nada que no se le enseñaría a quien tiene el token. Fuera datos personales que no hagan falta, fuera claves de API, fuera notas internas sobre el usuario.

Tampoco conviene que el token sea grande. Viaja en una cabecera HTTP en cada petición, y muchos servidores cortan por encima de ocho kilobytes. Lo habitual es guardar dentro un identificador y consultar el resto donde corresponda.