Anatomía de un JWT

Un JWT (JSON Web Token, RFC 7519) firmado en su forma habitual consta de tres partes separadas por puntos: la cabecera, la carga y la firma. La cabecera dice cómo se firmó (el algoritmo, alg; el tipo, typ; y qué clave, kid). La carga lleva las afirmaciones, llamadas claims: quién emitió el token (iss), de quién es (sub), para qué API (aud), cuándo se emitió (iat), cuándo caduca (exp) y lo que se le permite (aquí, scope). La firma resulta de aplicar la clave del emisor a la cabecera y la carga.

Cada parte se escribe en base64url, y eso solo es una forma de escribir bytes: cualquiera que tenga el token puede leer la cabecera y la carga sin ninguna clave. Lo que la firma aporta no es secreto sino detección: si alguien cambia una letra de la carga, la firma deja de cuadrar al verificarla. Abre la tabla de partes y compara quién puede leer cada una con quién puede alterarla sin que se note.

El claim exp marca el instante, en segundos desde 1970, a partir del cual el token ya no debe aceptarse; iat marca cuándo se emitió. Un token de acceso se diseña para vivir poco: si se filtra, el daño tiene fecha de caducidad. Una API de envíos con tokens de acceso de unos quince minutos tiene un margen de exposición razonable.

Compara en la tabla de tokens la distancia entre emisión y caducidad de cada uno. Cuatro siguen el patrón de la API. Uno se sale de él, y es el que más conviene preguntar a su dueño antes de dar nada por bueno.

Los tiempos de un JWT son enteros en segundos, así que medir una vida es una resta. Para saber si una cifra es mucho o poco, conviene convertirla: 3600 segundos son una hora; 86400, un día. Un token de servicio que dure semanas deja una ventana enorme si se copia de un registro o de una copia de seguridad.

Calcula la vida, en segundos, del token que aislaste en la tarea anterior.

El claim aud (audiencia) nombra la API para la que se emitió el token. Un token no es una llave maestra: es un permiso para un destino concreto, y cada API debe rechazar los que traigan otra audiencia. Eso solo funciona si el claim está correctamente puesto desde el emisor, así que auditarlo empieza por leerlo.

Busca en la tabla el token del usuario usr-2290 y lee a qué API está dirigido.

Como la carga la lee cualquiera que tenga el token, y los tokens acaban en cabeceras, registros de acceso, historiales del navegador y capturas de soporte, no es sitio para datos personales ni para nada confidencial. Si hace falta transportar datos que deban ir ocultos, el estándar tiene una variante cifrada (JWE), pero lo más prudente es llevar solo un identificador y consultar el dato en el servidor.

En la tabla de cargas con datos extra, el token TK-0830 lleva un correo y una dirección de entrega de un cliente.