JWT no es sinónimo de sesión. La RFC 7519 define JSON Web Token como un formato compacto para representar claims entre partes. Puede utilizarse como credencial dentro de una sesión autenticada, por ejemplo como access token, pero el estándar JWT no define por sí solo el inicio de sesión, la duración de la sesión, el cierre de sesión, la renovación ni la revocación. Esas reglas pertenecen a la arquitectura de autenticación y autorización.
La consecuencia práctica es importante: que un JWT siga siendo válido hasta su momento de expiración no significa que la aplicación deba considerar activa la sesión del usuario hasta ese instante, y que un usuario pulse "cerrar sesión" no invalida automáticamente todas las copias de un JWT ya emitido. Para entender el ciclo completo, hay que separar cuatro conceptos: token, sesión, expiración y revocación.
JWT, sesión, access token y refresh token no son lo mismo
| Elemento | Qué representa | Quién normalmente lo valida o utiliza | Qué no resuelve por sí solo |
|---|---|---|---|
| JWT | Un formato para transportar un conjunto de claims, protegido por JWS o JWE según corresponda. | La parte que recibe el token y aplica las reglas de validación del perfil utilizado. | No define política de sesión, cierre de sesión, almacenamiento ni revocación. |
| Sesión autenticada | El estado lógico en el que la aplicación reconoce una identidad autenticada y aplica un ciclo de vida. | La aplicación, el authorization server y otros componentes implicados en el estado autenticado. | No requiere JWT. Puede usar un identificador opaco asociado a estado en el servidor. |
| Access token | Credencial utilizada para acceder a recursos protegidos. En OAuth 2.0, su formato puede variar. | Resource server o API. | No es necesariamente un JWT y no debe confundirse con un refresh token. |
| Refresh token | Credencial utilizada para obtener nuevos access tokens cuando el actual expira o deja de ser válido. | Authorization server. La RFC 6749 indica que no se envía a los resource servers. | No autoriza directamente una llamada normal a la API y su emisión es opcional. |
Esta distinción también evita una expresión engañosa: "autenticación JWT" puede describir una arquitectura que utiliza JWT como credenciales, pero JWT es el formato del token, no el protocolo completo de autenticación ni la sesión en sí. Un sistema puede tener una sesión con cookie e identificador opaco, un access token JWT, un access token opaco o combinaciones diferentes.
Qué hace realmente la expiración de un JWT
El claim exp de la RFC 7519 identifica el momento a partir del cual el JWT ya no debe aceptarse para procesamiento. La especificación permite una pequeña tolerancia por diferencias de reloj, y el uso de exp es opcional en el estándar general, aunque los perfiles y las aplicaciones suelen imponer sus propias reglas.
Este mecanismo responde a una pregunta concreta: "¿este token sigue dentro de la ventana temporal en la que puede aceptarse?". Por sí solo, no responde a "¿el usuario sigue conectado?", "¿el usuario cerró sesión?", "¿la cuenta fue bloqueada?", "¿se cambió la contraseña?" o "¿un administrador terminó todas las sesiones?". Esas decisiones requieren estado o señales adicionales en la arquitectura.
Imagine un access token JWT válido durante diez minutos. Si el usuario cierra sesión en el segundo minuto y la API solo verifica firma, emisor, audiencia y exp, una copia de ese token ya obtenida puede seguir siendo aceptada hasta el final de la ventana. Para detener su uso antes de la expiración hace falta algún mecanismo de revocación, una consulta de estado o una credencial de sesión cuya validez pueda terminarse en el servidor.
El flujo arquitectónico: login, access token, expiración, refresh y revocación
- Login: la aplicación autentica al usuario y establece el estado requerido por el diseño, que puede incluir una sesión en el servidor, emisión de tokens o ambas cosas.
- Access token: el cliente recibe una credencial para acceder a la API. Si es un JWT, la API valida no solo el tiempo, sino también las reglas criptográficas y los claims exigidos por el perfil.
- Uso normal: mientras el token sea aceptable, puede autorizar llamadas dentro de los privilegios, la audiencia y las demás restricciones establecidas.
- Expiración: cuando se alcanza exp, ese JWT deja de aceptarse. Esto termina la utilidad de esa credencial concreta, no necesariamente toda la experiencia autenticada.
- Refresh: si la arquitectura utiliza un refresh token y sigue siendo válido, el cliente puede solicitar un nuevo access token al authorization server sin repetir inmediatamente todo el login.
- Revocación o logout: la arquitectura invalida en el servidor la sesión o las credenciales relevantes. Según el diseño, esto puede incluir revocar refresh tokens, marcar identificadores como inválidos, terminar una sesión server-side o consultar un estado de revocación.
Por tanto, expiración y cierre de sesión son eventos distintos. La expiración es una regla temporal de aceptación de una credencial. El logout es una acción del ciclo de sesión que debe provocar la invalidación adecuada del estado o de las credenciales que permitirían continuar autenticado.
Dónde entra el refresh token
En OAuth 2.0, los refresh tokens son credenciales utilizadas para obtener nuevos access tokens. Suelen tener una vida más larga que el access token y, por ello, presentan un riesgo diferente: si un refresh token es robado y sigue siendo utilizable, un atacante puede conseguir nuevas credenciales incluso después de que los access tokens anteriores expiren.
Por eso, el refresh token no debe tratarse simplemente como "un JWT que dura más". Su formato es independiente de la función que desempeña. La RFC 6749 señala que suele ser opaco para el cliente, y la RFC 9700, actual Best Current Practice de seguridad de OAuth 2.0, exige que los clientes públicos se protejan contra replay mediante refresh tokens vinculados al remitente o mediante rotación de refresh token.
Con la rotación, cada uso correcto produce un nuevo refresh token e invalida el anterior, mientras el servidor conserva suficiente información de relación para detectar una reutilización indebida. Esto reintroduce estado de forma deliberada en el authorization server, lo que es una elección de seguridad y control del ciclo de vida, no un fallo del modelo.
Revocación: cómo terminar la validez antes que el reloj
Revocar significa hacer inutilizable una credencial o autorización antes de que dejara de ser válida solo por el paso del tiempo. Existen estrategias diferentes, y cada una modifica el equilibrio entre simplicidad, escalabilidad y control inmediato.
Sesión con estado en el servidor
El cliente mantiene un identificador, normalmente en una cookie, y el servidor consulta un registro de sesión. El logout puede invalidar ese registro de inmediato. La ventaja es el control centralizado; el coste es mantener y consultar estado de sesión.
Access token JWT corto sin comprobación de revocación
La API puede validar el token localmente, reduciendo la dependencia de una consulta central en cada petición. A cambio, la revocación inmediata es limitada: un token copiado suele seguir siendo utilizable hasta que expira. Acortar la vida del access token reduce esa ventana, pero no la convierte en cero.
JWT con lista o estado de revocación
La aplicación puede mantener estado de revocación, por ejemplo asociado a un identificador de token, o consultar un mecanismo de estado. OWASP describe una denylist como una forma de abordar el problema de invalidación en arquitecturas con JWT, y al mismo tiempo advierte que la implementación debe considerar detalles como identificadores adecuados y validación estricta.
Revocación en OAuth 2.0
La RFC 7009 define un endpoint mediante el cual el cliente informa al authorization server de que un token ya no es necesario. La especificación exige soporte para revocar refresh tokens y recomienda soporte para revocar access tokens. El efecto exacto puede depender del tipo de token y de la política del servidor.
La rotación de claves no es un mecanismo de logout individual
Rotar o retirar una clave de firma puede invalidar muchos tokens a la vez y es útil para la gestión criptográfica o la respuesta a una posible vulneración. Sin embargo, como estrategia de cierre de sesión de un solo usuario es demasiado amplia porque afecta a todos los tokens que dependen de esa clave.
Trade-offs de los diseños más comunes
| Diseño | Estado central | Logout inmediato | Ventaja principal | Coste principal |
|---|---|---|---|---|
| Cookie + sesión server-side | Sí | Directo, al invalidar la sesión | Control sencillo del ciclo de vida | Almacenamiento y consulta de sesión |
| Access token JWT autocontenido, sin revocación | Poco durante la validación del access token | No para una copia ya emitida, salvo medidas adicionales | Validación local y desacoplada | Ventana hasta la expiración |
| JWT corto + refresh token controlado por el servidor | Sí en el flujo de refresh | Puede bloquear nuevas renovaciones; los access tokens actuales siguen dependiendo de su ventana o de revocación adicional | Combina access tokens cortos con una sesión renovable | Más componentes y políticas de rotación, almacenamiento y revocación |
| JWT + consulta de estado o denylist | Sí | Puede ser rápido según la consulta | Revocación antes de exp | Pierde parte de la ventaja de validación totalmente local y exige gestión de estado |
No existe un diseño universalmente mejor. Una API interna, una aplicación bancaria, una aplicación web tradicional y un ecosistema distribuido tienen requisitos diferentes de riesgo, latencia, escala y capacidad de revocación. La decisión arquitectónica debe empezar por el ciclo de vida deseado y las amenazas relevantes, no por una preferencia por JWT como tecnología.
Validar un JWT es más que comprobar la expiración
Aunque exp sea correcto, un JWT no debe aceptarse solo porque aún no haya expirado. La RFC 8725 exige una validación adecuada de los algoritmos y las operaciones criptográficas y orienta a validar emisor y audiencia cuando corresponda. Los perfiles específicos también pueden exigir tipo de token, subject, not-before, identificadores y otros claims.
Otro punto importante es la confidencialidad. Un JWT protegido por firma o MAC puede tener integridad sin que su contenido sea secreto. El cifrado es una propiedad distinta. Por tanto, la aplicación no debe asumir que la información incluida en un JWT firmado quedará oculta para el cliente o para quien obtenga el token.
Preguntas que ayudan a diagnosticar la arquitectura
- "Si el JWT expiró, ¿el usuario quedó desconectado?" No necesariamente. El access token expiró, pero una sesión o un refresh token todavía puede permitir emitir otro.
- "Si borro el token del navegador, ¿hice logout?" Eso elimina la copia local, pero no garantiza que otras copias ya obtenidas hayan sido invalidadas en el servidor.
- "¿El refresh token tiene que ser JWT?" No. La función del refresh token no exige JWT, y OAuth permite que su representación sea opaca para el cliente.
- "¿JWT hace que todo sea stateless?" No por definición. La revocación, los refresh tokens, la detección de replay, las sesiones administrativas y otras políticas pueden exigir estado en el servidor.
- "¿Un access token corto resuelve la revocación?" Limita la ventana de exposición, pero no ofrece invalidación inmediata por sí solo.
El modelo mental más seguro
Piense en JWT como un sobre estandarizado de claims que puede utilizar una arquitectura mayor. exp controla la validez temporal de ese sobre; el access token controla el acceso a recursos según su scope y perfil; el refresh token permite solicitar nuevas credenciales; y la sesión define el ciclo lógico de autenticación que la aplicación desea mantener.
Cuando el logout y la revocación importan, la arquitectura necesita un punto de control capaz de decir "esta sesión o esta autorización ya no es válida", aunque alguna credencial todavía no haya alcanzado su momento de expiración. Esa separación entre formato del token y ciclo de vida es lo que evita tratar JWT como si fuera, por sí solo, un sistema completo de sesión.
Fuentes y referencias
- IETF RFC 7519: JSON Web Token (JWT)
- IETF RFC 8725: JSON Web Token Best Current Practices
- IETF RFC 6749: The OAuth 2.0 Authorization Framework
- IETF RFC 7009: OAuth 2.0 Token Revocation
- IETF RFC 9700: Best Current Practice for OAuth 2.0 Security
- OWASP Cheat Sheet Series: Session Management
- OWASP Cheat Sheet Series: JSON Web Token
