Cómo funciona la autenticación con JWT: tokens sin sesiones
Cómo funciona la autenticación con JWT en un lienzo interactivo: las credenciales, el token firmado de tres partes y cómo se verifica cada petición sin estado.
Un JSON Web Token es una declaración firmada y autocontenida de quién eres: el servidor lo crea una vez al iniciar sesión, y cada petición posterior se demuestra con el token en lugar de consultar una sesión.
Cómo funciona la autenticación con JWT: tokens sin sesiones
El lienzo interactivo de FlowJam de esta explicación: cada carril, cada fila y cada flecha de arriba forma parte de un diagrama real de QueryChart que puedes abrir y editar.
Cómo leer este diagrama
- Lee de izquierda a derecha: Inicio de sesión, Emisión del token, Peticiones autenticadas.
- La fila del usuario y la del servidor se alternan, así que cada flecha es o bien el usuario aportando algo o bien el servidor decidiendo algo.
- Las dos formas de rechazo en lo alto de las columnas de inicio de sesión y de petición son los estados finales de fallo: cada decisión del lienzo alimenta una de ellas.
Demostrar quién eres
«El usuario envía su correo y su contraseña» y «El servidor verifica las credenciales contra la base de datos» son el único punto del flujo donde existe una contraseña. «¿Son válidas las credenciales?» se bifurca entre el camino feliz e «Inicio de sesión rechazado». Esto es autenticación convencional: la parte del JWT empieza después de que la comprobación de credenciales tenga éxito.
Acuñar el token
«El servidor construye la cabecera, el payload y la firma» es el corazón del diagrama. La cabecera nombra el algoritmo de firma; el payload lleva los claims (las afirmaciones que transporta el token) —el id del usuario, la caducidad y los ámbitos que haya—; la firma los ata para que el token no se pueda alterar sin que se note. «El servidor firma el token con su clave secreta» es el acto que lo hace fiable: solo un servidor que tenga el secreto puede producir una firma válida. «El cliente recibe el JWT y lo guarda» entrega el artefacto al cliente, donde vive hasta que caduca.
Verificación sin estado
«El cliente envía el JWT en la cabecera Authorization» arranca la parte repetida del flujo, y «El servidor verifica la firma con su clave secreta» es la razón de que esto escale: volver a comprobar una firma es un cálculo, no una consulta a la base de datos, así que no hay ningún almacén central de sesiones al que acudir. «¿Es válida la firma y no ha caducado?» añade la comprobación temporal y enruta los tokens no válidos o caducados a «Petición rechazada con 401» y los válidos a «El servidor confía en los claims y procesa la petición».
Relaciones clave y conclusiones
- Un JWT son tres partes —cabecera, payload y firma— unidas por puntos; el payload es legible, pero delata cualquier manipulación.
- La firma convierte la identidad en una capacidad: tener un token válido y no caducado es lo que autentica la petición.
- La verificación no tiene estado: recalcular la firma sustituye a la consulta de sesión.
- El cliente tiene que guardar el token a salvo y enviarlo con cada petición, así que su caducidad es la verdadera frontera de seguridad.
- JWT y OAuth encajan: OAuth decide qué puede hacer el cliente, y JWT es un formato habitual para el token que lo transporta.
Cuándo usar este diagrama
- Enseñar a un equipo de backend nuevo por qué no hace falta ninguna tabla de sesiones y qué demuestra realmente la firma.
- Elegir entre JWT y sesiones en el servidor para un servicio donde el escalado horizontal vuelve incómodo el estado compartido.
- Revisar los claims de un token —caducidad, emisor, audiencia— antes de confiar en él dentro de un microservicio.
Cómo funciona
Enumera los claims que llevan de verdad tus tokens
En el paso de «la cabecera, el payload y la firma», añade los claims reales que emites —sub, exp, iss, aud y los ámbitos que uses— para que el diagrama documente el contrato de tu token.
Añade el flujo de renovación
Inserta la ruta del token de actualización (refresh token) después de la caducidad: el cliente presenta un token de actualización de vida larga, el servidor acuña un token de acceso nuevo y la sesión continúa sin un nuevo inicio de sesión.
Nombra tu estrategia de claves de firma
Anota el paso de la firma con tu gestión de claves —un único secreto compartido (HS256) o un par de clave pública y privada (RS256)—, porque esa elección decide quién puede verificar el token.
Añade las ramas de fallo
Incluye los tokens caducados, mal formados y manipulados como estados finales explícitos, para que el diagrama cubra los rechazos que devuelve de verdad tu API.
Preguntas frecuentes
¿Qué es un JWT y qué contiene?
Un JSON Web Token es una cadena de tres partes separadas por puntos: una cabecera que indica el algoritmo de firma, un payload de claims sobre el usuario y sobre la vida del token, y una firma. La cabecera y el payload son JSON codificado en base64 —legible por cualquiera— y la firma es lo que impide cambiarlos sin la clave de firma.
¿Por qué se dice que la autenticación con JWT no tiene estado?
Porque el servidor no guarda nada sobre la sesión. Cada petición llega con el token, y el servidor verifica la firma y la caducidad en el momento. No hay ninguna tabla de sesiones que consultar ni estado que replicar entre servidores, y eso es lo que permite que el enfoque escale horizontalmente. El coste es que un token no se puede revocar antes de que caduque sin maquinaria adicional.
¿Es seguro un JWT si cualquiera puede leer el payload?
Leer y confiar son cosas distintas. El payload no está cifrado —no pongas secretos en él—, pero la firma hace que cualquier modificación invalide el token, así que un cliente no puede cambiar sus propios claims. Para la seguridad del transporte, el token viaja dentro de HTTPS, y los datos a los que da acceso los protege el servidor de recursos aplicando los claims.
¿Cómo se relacionan JWT y OAuth?
Resuelven mitades distintas del problema. OAuth es el protocolo de autorización: cómo obtiene un cliente el permiso y el token. JWT es un formato de token. En la práctica, los tokens de acceso de OAuth suelen ser JWT: el servidor de autorización firma un JWT que transporta los ámbitos, y los servidores de recursos lo verifican. Este lienzo cubre la mitad de la autenticación; el diagrama de OAuth cubre la mitad de la delegación.
Edita este diagrama en QueryChart (FlowJam)
Abre ese mismo lienzo de JWT como tu propio diagrama, renombra el cliente y el servidor con tus servicios y anota tus propios claims.