JWT (JSON Web Token) es un formato compacto para transmitir datos firmados, casi siempre información sobre un usuario autenticado. Un token consta de tres partes separadas por puntos: header.payload.signature. En el ecosistema hispanohablante, PHP con Laravel y Node con Express siguen siendo las combinaciones más habituales para emitir y verificar estos tokens, tanto en España como en Latinoamérica.
La ñ y los acentos en los claims
Un payload como {"nombre": "Peña", "ciudad": "Logroño"} se codifica igual que cualquier otro JSON: Base64URL solo trabaja sobre los bytes UTF-8, sin importar si son letras con tilde o la eñe. El detalle práctico es que cada carácter con tilde o la ñ ocupa 2 bytes en UTF-8 en lugar de 1, así que un payload con nombres hispanohablantes reales es ligeramente más largo, byte a byte, que uno equivalente en inglés puro.
Las tres partes del token
- Header — un JSON con el tipo de token y el algoritmo de firma (por ejemplo, HS256 o RS256), codificado en Base64URL.
- Payload — un JSON con los "claims": datos del usuario, momento de emisión, caducidad, etc., también en Base64URL.
- Signature — una firma calculada sobre el header y el payload con una clave secreta o privada, que confirma que el token no se ha modificado.
Base64URL, no Base64 normal
JWT usa una variante de Base64 con un alfabeto seguro para URL: los caracteres + y / se sustituyen por - y _, y normalmente se omite el relleno =. Esto permite insertar el token en una URL o cabecera sin codificación adicional.
Una distinción importante: decodificar ≠ verificar
El header y el payload son solo Base64URL: cualquiera puede decodificarlos y leer su contenido sin ninguna clave. Decodificar un token no demuestra que los datos no hayan sido alterados. Solo se puede confiar en el contenido del token después de verificar su firma con la clave correspondiente, y esa verificación la hace el servidor, no un cliente que simplemente mira lo que hay dentro del token.
Un ataque peligroso: sustituir el algoritmo por «none»
La especificación JWT permite el algoritmo none: un token sin firma. Si el backend confía ingenuamente en el campo alg del encabezado del token en lugar de verificar la firma con un algoritmo fijo y conocido de antemano, un atacante puede sustituir alg por none, eliminar la firma, y el token superará la verificación con datos arbitrarios. Las bibliotecas JWT robustas exigen indicar explícitamente el algoritmo esperado al verificar, precisamente para protegerse de este ataque.
Un caso frecuente: fintech y banca digital en LatAm
Buena parte de las fintechs y bancos digitales de la región (Argentina, México, Colombia, Chile) exponen sus APIs de open banking con autenticación basada en JWT de vida corta, a menudo con un refresh token aparte. Revisar el campo exp de un token durante una integración es, en la práctica, el primer paso para diagnosticar por qué una API "de repente" empieza a rechazar peticiones que antes funcionaban.