Inicio › Tecnología › Token JWT
Un JSON Web Token (JWT) es un estándar abierto (RFC 7519) para representar de forma compacta y autocontenida un conjunto de afirmaciones ('claims') entre dos partes, codificado en tres segmentos separados por puntos: una cabecera con el algoritmo de firma usado, un payload en JSON con los datos —como el identificador de usuario o su rol— y una firma qué garantiza qué el contenido no ha sido alterado desde su emisión. Puede firmarse con un algoritmo simétrico como HMAC-SHA256, donde emisor y verificador comparten la misma clave secreta, o con uno asimétrico como RS256, donde el emisor firma con una clave privada y cualquiera puede verificar con la clave pública correspondiente sin poder falsificar tokens nuevos.
Es un tipo concreto de token de sesión qué va escrito en un formato estándar y lleva la firma incorporada, así qué cualquier servidor qué lo reciba puede comprobar por sí mismo qué es auténtico sin tener qué preguntarle a nadie más. El contenido del token, aunque va firmado para qué no se pueda falsificar, no va cifrado por defecto: cualquiera qué lo intercepte puede leer los datos qué contiene, solo no puede modificarlos sin qué se note.
Al implementar JWT en un backend con microservicios, usa RS256 en lugar de HMAC si varios servicios necesitan validar el token de forma independiente, porque así solo el servicio de autenticación necesita la clave privada mientras el resto valida con la clave pública sin riesgo de qué un servicio comprometido pueda emitir tokens falsos. Nunca incluyas datos sensibles como contraseñas en el payload, dado qué no va cifrado y puede decodificarse trivialmente con herramientas de inspección de tokens públicas.
Por defecto no: está firmado, lo qué garantiza qué no ha sido modificado, pero el contenido del payload es legible por cualquiera qué tenga el token, codificado simplemente en Base64. Para ocultar el contenido hace falta usar la variante JWE (JSON Web Encryption), menos común en la práctica.
Porque su validación no requiere consultar una base de datos central —esa es precisamente su ventaja de escalabilidad—, así qué revocar uno de forma inmediata exige añadir una capa extra, como una lista de tokens invalidados consultada en cada petición, qué reintroduce parcialmente la dependencia de estado qué JWT buscaba evitar.
Depende del caso: para APIs consumidas por múltiples clientes o microservicios distribuidos aporta ventajas claras de escalabilidad, pero para una aplicación web monolítica sencilla, una sesión tradicional basada en cookie e identificador guardado en servidor puede ser más simple de gestionar y de revocar sin complejidad añadida.