CicloUrbana ya sabe quién es cada ciudadano de Ribalta, pero lo pregunta de una forma que no aguanta el uso real. Con HTTP Basic, la aplicación móvil tiene que guardar la contraseña de Marta y enviarla en cada petición: al abrir el mapa, al consultar una estación, al iniciar un alquiler. La credencial más valiosa del usuario recorre la red decenas de veces al día, el servidor calcula un BCrypt de noventa milisegundos en cada una, y no hay manera de caducar un acceso sin obligar a cambiar la contraseña.

Esta lección lo resuelve con el patrón estándar de las APIs modernas: la contraseña se envía una sola vez, y a cambio el servidor emite un token firmado y caducable que el cliente presenta después en la cabecera Authorization: Bearer. Veremos qué es exactamente un JWT campo a campo, lo implementaremos con JJWT y un filtro propio, añadiremos tokens de refresco con rotación y revocación en base de datos, y afrontaremos con honestidad las dos preguntas incómodas del modelo sin estado: dónde guarda el cliente el token y qué significa realmente cerrar sesión.

Advertencia. Todos los secretos, claves y tokens de esta lección son ficticios y están truncados; ninguno debe reutilizarse. El secreto de firma jamás se escribe en el repositorio: se inyecta por variable de entorno o gestor de secretos. Y una implementación propia de JWT, aunque use una librería sólida, debe ser revisada por un profesional de seguridad antes de exponerse a Internet; el apartado 15 explica la alternativa que evita escribir este código.

1. Por qué una app móvil necesita autenticación sin estado
2. Sesión con cookie frente a token: la comparación honesta
3. Anatomía de un JWT
4. Los claims: estándar y propios de CicloUrbana
5. Algoritmos de firma: HS256 frente a RS256
6. Firmado no es cifrado
7. JJWT y JwtProperties
8. ServicioJwt: generar, leer y validar
9. FiltroAutenticacionJwt
10. Registrar el filtro en la cadena de seguridad
11. POST /api/v1/auth/login
12. Tokens de refresco: rotación y revocación
13. Cerrar sesión en un mundo sin estado
14. Dónde guarda el token el cliente
15. Documentar el esquema en OpenAPI y la alternativa para producción
16. Probar el flujo completo con curl
17. Errores Comunes y Consejos
18. Ejercicios

La alternativa clásica al token es la sesión en el servidor: el usuario entra una vez, el servidor guarda su estado en memoria y le entrega una cookie con un identificador. Funciona muy bien para una web tradicional y muy mal para CicloUrbana:

• El cliente no es un navegador. Una aplicación móvil no gestiona cookies de forma natural, y la política de terceros de los navegadores complica cada vez más el escenario web.
• La sesión vive en una instancia. Con tres réplicas detrás de un balanceador, la sesión de Marta está en la número 2 y las otras dos no la conocen: las salidas son sesión pegajosa (frágil) o replicación (cara). Con un token, cualquier instancia atiende cualquier petición.
• Contradice la restricción REST de 03-01, que exige que cada petición contenga toda la información necesaria, y consume memoria proporcional al número de usuarios conectados.

La solución sin estado invierte el almacenamiento: el estado viaja con el cliente, firmado por el servidor para que no pueda manipularlo. El servidor no recuerda nada; solo verifica una firma.

Los tres inconvenientes del JWT hay que decirlos sin adornos, porque casi nunca se mencionan:

No se puede revocar fácilmente. Un token robado es válido hasta que expira y no hay nada en el servidor que lo invalide: si Marta pierde el móvil, su token sigue funcionando. La defensa principal es la caducidad corta, y por eso el apartado 12 introduce los tokens de refresco. Ocupa espacio: un JWT con roles ronda los 400 bytes que viajan en cada petición, un coste real sobre una conexión móvil. Y es peligroso si se almacena mal: guardarlo en localStorage lo hace legible por cualquier JavaScript de la página, de modo que un XSS pasa de ser un problema molesto a un robo de identidad completo (apartado 14).

Un JWT no es la mejor opción siempre. Para una aplicación web clásica con vistas en el servidor, la sesión con cookie sigue siendo más simple y más segura. CicloUrbana elige el token porque su cliente es móvil y su API es sin estado, no porque sea moderno.

Un JSON Web Token (RFC 7519) son tres bloques codificados en Base64URL y separados por puntos:

Al decodificar los dos primeros bloques —que es trivial: echo '<bloque>' | base64 -d— se obtiene JSON:

Y el tercer bloque, la firma, se calcula así:

Base64URL no es cifrado: es una codificación reversible que existe solo para que el token viaje sin caracteres problemáticos en una URL o una cabecera. Cualquiera puede leer la carga útil; lo que nadie puede hacer sin el secreto es producir una firma válida. La verificación funciona así:

Si un atacante cambia "roles":["ROLE_CIUDADANO"] por "roles":["ROLE_ADMIN"], la carga útil cambia, el HMAC recalculado ya no coincide con la firma que acompaña al token y el servidor lo rechaza. No puede recalcular la firma correcta porque no tiene el secreto.

Cada campo de la carga útil es un claim, una afirmación sobre el sujeto. El RFC define siete registrados:

Los tres primeros importan más de lo que parece. Validar iss y aud evita que un token emitido por otro sistema —o para otro servicio de la misma organización— sea aceptado aquí, un fallo real y frecuente en arquitecturas con varios servicios; y jti es lo que hace posible una lista de revocación (apartado 13). A ellos CicloUrbana añade dos claims propios:

Cada claim que añades es un compromiso. Agranda el token y, sobre todo, congela un dato: si un administrador retira el rol OPERARIO a Luis, su token sigue diciendo que lo tiene hasta que caduque. Con quince minutos de vida es asumible; con veinticuatro horas, no. Es la limitación que anticipamos en el ejercicio 3 de 05-03, y la razón de fondo de que el token de acceso deba ser corto.

CicloUrbana usa HS256, porque hoy la misma aplicación emite y verifica los tokens y un secreto compartido es la solución más simple y perfectamente segura en ese escenario. Hay que cambiar a RS256 en cuanto más de un servicio necesite verificar: con HS256, quien puede verificar también puede emitir, así que compartir el secreto con cinco microservicios significa que cinco equipos pueden fabricar tokens de administrador. Con RS256 los servicios reciben solo la clave pública y verifican sin poder falsificar. Es el escenario del módulo 7, y el motivo de que los proveedores de identidad usen siempre algoritmos asimétricos.

La vulnerabilidad alg: none. Las primeras implementaciones de JWT aceptaban un token cuya cabecera declarase "alg":"none" y lo daban por válido sin firma. Un atacante solo tenía que quitar la firma y cambiar la cabecera. Otra variante consistía en cambiar RS256 por HS256 para que el servidor usara la clave pública como secreto HMAC —una clave que el atacante conoce—. La defensa es la misma en ambos casos: el algoritmo esperado lo decide el servidor, nunca el token. JJWT 0.12 lo hace correctamente si se usa verifyWith(clave), que fija el algoritmo a partir del tipo de clave. Nunca escribas código que lea alg de la cabecera para decidir cómo verificar.

Advertencia destacada. La carga útil de un JWT es legible por cualquiera que tenga el token: basta con decodificar Base64URL, sin secretos ni herramientas. La firma garantiza integridad y autenticidad, no confidencialidad.

Lo que nunca debe ir en un JWT:

• Contraseñas o hashes de contraseñas.
• DNI, dirección postal, teléfono, datos de salud o cualquier dato personal sensible.
• Números de tarjeta, datos bancarios, claves de API, secretos internos o rutas de infraestructura.
• Información comercial reservada, como el importe acumulado de los alquileres.

Lo que sí es razonable: el identificador del usuario, su correo si el servicio lo trata como identificador público, sus roles y las marcas de tiempo. La regla práctica: si no lo escribirías en una postal, no lo pongas en un JWT. Cuando de verdad hace falta confidencialidad existe JWE (JSON Web Encryption), que cifra la carga útil; es notablemente más complejo, y la solución habitual es más simple: no meter el dato en el token y consultarlo en el servidor cuando haga falta.

Las tres son necesarias y el reparto es deliberado: jjwt-api contiene las interfaces y es la única con la que compilas; jjwt-impl y jjwt-jackson son implementaciones en ámbito runtime, lo que impide acoplar tu código a detalles internos. Si aparece un ClassNotFoundException sobre DefaultJwtBuilder, es que falta jjwt-impl. Y ojo: JJWT no está gestionado por el spring-boot-starter-parent, así que la versión hay que fijarla a mano y revisarla periódicamente (05-05).

La configuración, con @ConfigurationProperties tipadas como en 02-05:

Cuatro decisiones importantes:

El secreto viene de una variable de entorno. ${JWT_SECRETO} sin valor por defecto: si la variable no existe, la aplicación no arranca, que es exactamente lo que se quiere. Escribir un secreto por defecto en el YAML es peor que no tener seguridad, porque crea una falsa sensación de tenerla: acaba en Git, en la imagen Docker y en el portátil de todo el equipo, y ese mismo valor termina en producción con una frecuencia que asusta.

@Size(min = 43) no es arbitrario. HS256 exige una clave de al menos 256 bits, que en Base64 son 43 caracteres; JJWT rechaza claves más cortas con WeakKeyException, y validarlo al arrancar convierte ese fallo en tiempo de ejecución en un error de configuración comprensible. Un secreto adecuado se genera, nunca se inventa:

El constructor compacto valida la política, no solo el formato: que alguien configure expiracion: 24h no es un error de tipo pero sí de seguridad, y el arranque lo impide. Y el secreto se rota, como cualquier credencial: en producción vive en un gestor de secretos (Vault, AWS Secrets Manager, los secrets de Kubernetes) y se cambia periódicamente, sabiendo que rotarlo invalida todos los tokens en circulación.

Cinco detalles que hacen que este código sea correcto y no solo funcional:

1. verifyWith(clave) fija el algoritmo a partir del tipo de clave. Es lo que cierra la puerta a alg: none y a la confusión RS256/HS256 del apartado 5.
2. requireIssuer y requireAudience rechazan tokens ajenos. Se olvidan casi siempre.
3. clockSkewSeconds(30) tolera el desfase de reloj entre máquinas. Sin él, dos servidores con dos segundos de diferencia producen rechazos intermitentes imposibles de reproducir. Y el Clock inyectado —el bean de 03-03— hará posible probar la caducidad en el módulo 6 sin esperar quince minutos.
4. Un token caducado se registra en DEBUG; una firma inválida, en WARN. Lo primero es el funcionamiento normal; lo segundo puede ser un ataque, y mezclarlos hace inútil el log (09-05).
5. Nunca se registra el token: un token en un log es una credencial en un log. Y .audience().add(...).and() es la API fluida de JJWT 0.12, que cambió respecto a 0.11, así que mucho código de internet no compilará contra esta versión.

El filtro es la pieza que convierte una cabecera HTTP en un usuario autenticado. Hereda de OncePerRequestFilter, igual que el FiltroTraza de 03-06, para garantizar una sola ejecución por petición aunque haya reenvíos internos.

Cinco decisiones que conviene entender:

El filtro nunca rechaza la petición. Si no hay token, o es inválido, simplemente no autentica y deja continuar la cadena: quien decide si esa petición necesitaba autenticación es el AuthorizationFilter de 05-01, y quien produce el 401 es el AuthenticationEntryPoint de 05-03. Esta separación es la que permite que GET /api/v1/estaciones siga siendo público mientras /api/v1/alquileres no lo es, con el mismo filtro.

No se consulta la base de datos: toda la información —id, correo, roles— viene del token. Es lo que hace el modelo sin estado y rápido, y también lo que congela los roles hasta la caducidad; la alternativa, cargar el UserDetails en cada petición, es más segura y sacrifica la mayor parte de la ventaja.

Se comprueba si ya hay autenticación antes de escribir en el contexto, para no pisar la de otro mecanismo. UsuarioAutenticado necesita un segundo constructor que reciba id, correo y autoridades, sin entidad ni hash: getPassword() devolverá null y no pasa nada, porque en este camino nadie compara contraseñas. Y se guardan los details con la IP: información valiosa para la auditoría de 05-03.

addFilterBefore(filtroJwt, UsernamePasswordAuthenticationFilter.class) coloca el filtro en una posición concreta de la cadena de 05-01: después de SecurityContextHolderFilter y CorsFilter —así el contexto está limpio y las peticiones de sondeo CORS ya se han resuelto— y antes de ExceptionTranslationFilter y AuthorizationFilter, que es lo imprescindible: cuando la autorización evalúe las reglas, el contexto ya debe contener al usuario. Y aquí desaparecen httpBasic y formLogin, tal como anunciamos en 05-02: a partir de ahora la única forma de autenticarse contra la API es un token.

El controlador es un @PostMapping("/login") en el AutenticacionController de 05-03 que recibe @Valid @RequestBody LoginRequest y devuelve 200 OK con el TokenResponse.

Tres puntos. La autenticación no se reimplementa: se delega en el AuthenticationManager, que ya sabe comparar hashes en tiempo constante, comprobar si la cuenta está activa y publicar los eventos de fallo; reescribir aquí un if (codificador.matches(...)) perdería todo eso. Si falla lanza BadCredentialsException, que hay que traducir a un 401 uniforme en ManejadorGlobalExcepciones —este sí lo ve, porque ocurre dentro de un controlador—. Y la respuesta no revela nada del usuario: solo tokens.

Hay una tensión evidente. Un token de acceso corto limita el daño de un robo, pero obliga al ciudadano a escribir su contraseña cada quince minutos. Un token largo es cómodo y peligroso.

La solución son dos tokens con papeles distintos:

El token de refresco no es un JWT, y es deliberado: como el servidor lo guarda de todos modos para poder revocarlo, no hay ventaja en que sea autocontenido, y una cadena aleatoria larga es más corta, más opaca y no revela nada.

Se guarda el SHA-256 del token, no el token, por el mismo razonamiento que con las contraseñas: si alguien lee la tabla, no obtiene credenciales utilizables. Aquí basta un hash rápido, porque el token es una cadena aleatoria de 256 bits y no una contraseña adivinable por diccionario. El endpoint de refresco, con rotación:

Cuatro ideas clave:

Rotación: cada uso del token de refresco lo invalida y emite uno nuevo. Reduce la ventana de un token robado y, sobre todo, hace detectable el robo.

Detección de reutilización: si llega un token ya revocado, o bien es el ladrón usando uno que la víctima ya rotó, o bien al revés; no hay forma de saber cuál, así que se revocan todos los tokens de refresco de ese usuario y se le obliga a autenticarse de nuevo. Es molesto y es lo correcto.

Los roles se recargan de la base de datos, y es el momento en que el cambio de privilegios del ejercicio 3 de 05-03 surte efecto: como máximo quince minutos después. El mensaje de error es siempre el mismo, no exista el token, esté revocado o haya caducado. Y falta una pieza operativa: una tarea programada que borre los caducados, o la tabla crece sin límite (07-03).

POST /api/v1/auth/logout no puede invalidar el token de acceso. Está firmado, es válido y el servidor no guarda nada sobre él. Las opciones reales:

CicloUrbana implementa el cierre de sesión como revocación del token de refresco: el token de acceso sigue valiendo hasta quince minutos y luego no se puede renovar. Es una decisión consciente, y hay que ser honestos sobre lo que significa: durante esos quince minutos, un token robado sigue funcionando.

Cuando eso no es tolerable —una operación bancaria, un cierre de sesión por sospecha de compromiso— la solución es una lista de revocación de los jti en una caché rápida como Redis, con expiración automática al caducar el token; consultarla en cada petición reintroduce estado, pero acotado, y la caché distribuida se trata en 09-02. En cualquier caso, la defensa principal sigue siendo la expiración corta: todo lo demás son mitigaciones.

Es la parte del sistema que el backend no controla y donde más incidentes reales se producen.

Advertencia. localStorage es el consejo más repetido de internet y el peor. Cualquier XSS —una dependencia de JavaScript comprometida, un campo mal escapado— permite leer el token y suplantar al usuario desde otra máquina. Una cookie HttpOnly no es legible por JavaScript ni siquiera con XSS.

La app móvil de CicloUrbana, que es el cliente principal, usa el llavero del sistema: Keychain en iOS, EncryptedSharedPreferences o Keystore en Android. Para el panel web del ayuntamiento la recomendación es la cookie HttpOnly; Secure; SameSite=Strict con protección CSRF reactivada —recuerda la advertencia de 05-02: al volver la credencial a una cookie, la condición que permitía desactivar CSRF deja de cumplirse—, o bien el patrón mixto de token de acceso en memoria y refresco en cookie HttpOnly. Y en cualquier caso, HTTPS obligatorio: sin TLS todo lo anterior es irrelevante, porque el token viaja legible por la red (05-05).

El Swagger UI de 03-07 dejó de funcionar contra los endpoints protegidos: no tiene dónde escribir el token. Se arregla declarando el esquema de seguridad en ConfiguracionOpenApi:

Aparece entonces el botón Authorize en la interfaz y springdoc añade la cabecera a todas las llamadas; los endpoints públicos se marcan con @SecurityRequirements vacío para que la documentación no mienta.

Todo el código de esta lección es una implementación propia: excelente para entender el mecanismo, y en un sistema real conviene no escribirlo. Spring ofrece un módulo mantenido y auditado:

Con esas líneas desaparecen ServicioJwt, FiltroAutenticacionJwt y la gestión de secretos: el BearerTokenAuthenticationFilter de 05-01 se encarga usando Nimbus por debajo, y las claves públicas se obtienen del JWKS del proveedor y se rotan solas.

El criterio: si el sistema tiene un solo servicio, un cliente y requisitos sencillos, la implementación propia con una librería sólida es aceptable. En cuanto aparezcan varios servicios, inicio de sesión con proveedores externos, segundo factor o requisitos de cumplimiento normativo, usa un proveedor de identidad. El coste de mantener seguridad propia crece mucho más rápido de lo que parece.

Los pasos 5 y 7 son los importantes: el 5 demuestra que el token es legible por cualquiera —de ahí la advertencia del apartado 6— y el 7, que no es modificable.

Poner datos sensibles en la carga útil. Va firmada, no cifrada: un DNI en un JWT es un DNI público.

Escribir el secreto en application.yml, o usar uno corto e inventado. Un secreto en el YAML acaba en Git, en la imagen y en el portátil de todo el equipo; y misecreto123 no llega a 256 bits. Variable de entorno sin valor por defecto, generado con openssl rand -base64 48. Y nada de tokens de acceso de 24 horas «para que no moleste»: multiplican por 96 la ventana de un robo y congelan los roles todo ese tiempo.

Que el filtro devuelva 401 directamente, o registrarlo en la posición equivocada de la cadena. Lo primero rompe los endpoints públicos —el filtro autentica si puede, y la decisión es del AuthorizationFilter—; lo segundo, si queda tras AuthorizationFilter, hace que todo devuelva 401.

No validar iss ni aud, con lo que un token emitido por otro sistema con el mismo secreto sería aceptado; o leer alg del token para decidir cómo verificar, que es la vulnerabilidad alg: none. El algoritmo lo fija el servidor.

Guardar el token de refresco en claro en la base de datos, o registrar cualquier token en un log aunque sea truncado. Un token es una credencial; guarda su SHA-256 y no lo escribas nunca.

Consejo: expiración corta más refresco con rotación —15 minutos de acceso, 30 días de refresco rotatorio con detección de reutilización— es el equilibrio que funciona. Y usa el Clock inyectado en ServicioJwt: en el módulo 6 podrás probar la caducidad adelantando el reloj en lugar de esperar.

Un token de CicloUrbana tiene esta carga útil. Detecta cuatro problemas de seguridad o diseño y propón la versión corregida.

Implementa ServicioJwt.validar(String) de forma que distinga tres resultados —token válido, token caducado y token inválido— mediante un tipo propio en lugar de un Optional, y explica qué debe hacer el filtro con cada uno y a qué nivel de log corresponde.

Diseña el flujo completo para este requisito del ayuntamiento: «cuando un ciudadano cambia su contraseña, todas sus sesiones abiertas en otros dispositivos deben cerrarse inmediatamente». Ten en cuenta que el token de acceso no se puede revocar.

Solución 1

Problema 1 — dni. Dato personal identificativo, legible por cualquiera con el token y sujeto al RGPD. Fuera. Problema 2 — contrasenaHash, el fallo más grave: entrega el hash a cualquiera que capture el token, permitiendo un ataque de diccionario sin límite de intentos y sin dejar rastro en el servidor. Fuera, siempre.

Problema 3 — importeAcumulado. Dato comercial reservado y, además, un dato que cambia: quedaría congelado hasta la caducidad y mostraría cifras obsoletas si el cliente se fiara de él. Se consulta por API. Problema 4 — expiración de siete días (exp - iat = 604 800): un token robado vale una semana, y los cambios de rol tardan una semana en aplicarse. Faltan además iss, aud y jti, sin los cuales no se puede validar la procedencia ni revocar por identificador.

Regla para decidir qué entra: solo lo que se necesita en cada petición para autorizar, no cambia durante la vida del token y no sería un problema en una postal. El nombre podría quedarse si la app lo muestra —no es sensible—, pero engorda el token: es preferible pedirlo una vez a /api/v1/usuarios/yo.

Solución 2

Qué hace el filtro con cada caso. Válido: autentica. Caducado: no autentica, pero tampoco es un error; es el funcionamiento normal cada quince minutos, va a DEBUG, y la cabecera de pista permite a la app móvil distinguir «renueva el token» de «vuelve a iniciar sesión» sin exponer nada. Inválido: no autentica y va a WARN, porque una firma incorrecta es un intento de manipulación o un cliente roto, y un pico de estos eventos debe disparar una alerta (09-05). La ventaja del tipo sellado sobre el Optional es que es imposible olvidar un caso: el switch sobre una interfaz sealed debe ser exhaustivo o no compila, y en las pruebas del módulo 6 se puede afirmar sobre el motivo exacto.

Solución 3

El problema: el token de acceso de los otros dispositivos es válido y no hay nada en el servidor que lo invalide; revocar los tokens de refresco cierra la puerta futura, pero deja hasta quince minutos de acceso vigente. Solución completa, en cuatro piezas. 1. Marca de invalidación en el usuario, con una migración V7__anadir_invalidacion_tokens.sql que ejecuta ALTER TABLE usuarios ADD COLUMN tokens_invalidos_antes_de TIMESTAMPTZ;. 2. Al cambiar la contraseña, en la misma transacción: guardar el hash nuevo, poner tokensInvalidosAntesDe = ahora y revocar todos los tokens de refresco del usuario. 3. Comprobación en el filtro, aprovechando que el iat del token dice cuándo se emitió: si es anterior a la marca, el token muere.

4. El coste, y cómo pagarlo. Esto reintroduce una consulta por petición, justo lo que el modelo sin estado evitaba. Tres formas de amortiguarlo, de menor a mayor esfuerzo: cachear la marca por usuario con expiración corta (09-02); mantener en caché solo los usuarios con invalidación reciente, que son poquísimos, y tratar la ausencia como «sin invalidación»; o incluir la marca como claim en el token, aunque entonces solo protege a partir del siguiente refresco y no resuelve el requisito.

La lección de fondo: el requisito «cerrar sesión inmediatamente en todas partes» es incompatible con la autenticación puramente sin estado. Toda solución paga con estado en el servidor. Lo honesto es reconocerlo, elegir dónde se paga y dejarlo documentado, no fingir que el JWT lo resuelve todo. Y conviene preguntar antes si «inmediatamente» significa de verdad cero segundos o si quince minutos son aceptables: la respuesta cambia por completo la arquitectura.

CicloUrbana autentica ya como una API moderna. Sabes por qué una aplicación móvil necesita autenticación sin estado —el cliente no es un navegador, la sesión no sobrevive al balanceador y la restricción REST de 03-01 lo exige— y has comparado sesión y token con honestidad, sin ocultar los tres inconvenientes reales del JWT: no se revoca con facilidad, ocupa espacio en cada petición y es peligroso si el cliente lo almacena mal. Sabes también que para una web clásica con vistas en el servidor la sesión con cookie sigue siendo la opción más simple y más segura: CicloUrbana elige el token por sus requisitos, no por moda.

Conoces un JWT por dentro: cabecera, carga útil y firma en Base64URL, el HMAC que ata las dos primeras partes al secreto del servidor, y el hecho central de que Base64URL no es cifrado. Manejas los claims registrados —iss, sub, aud, exp, iat, jti— y los dos propios del proyecto, roles e idUsuario, sabiendo que cada uno agranda el token y congela un dato hasta la caducidad. Has comparado HS256 con RS256 y sabes cuándo obliga a cambiar la arquitectura: en cuanto un segundo servicio tenga que verificar, porque con un secreto compartido quien verifica también puede emitir. Y conoces la vulnerabilidad alg: none y su defensa: el algoritmo lo decide el servidor, nunca el token.

Has implementado el sistema completo con JJWT 0.12: las tres dependencias con sus ámbitos, JwtProperties validadas con un secreto que llega por variable de entorno y sin valor por defecto —de modo que la aplicación no arranca si falta—, con longitud mínima de 43 caracteres Base64 y una comprobación de política que impide configurar tokens de más de una hora. ServicioJwt genera, extrae y valida con verifyWith, requireIssuer, requireAudience, tolerancia de reloj y un Clock inyectado que hará posible probar la caducidad en el módulo 6. FiltroAutenticacionJwt, un OncePerRequestFilter registrado con addFilterBefore delante de UsernamePasswordAuthenticationFilter, nunca rechaza: autentica si puede y deja la decisión al AuthorizationFilter, que es justo lo que permite convivir endpoints públicos y protegidos en la misma cadena. Y con POST /api/v1/auth/login delegando en el AuthenticationManager de 05-03, HTTP Basic y el formulario han desaparecido de la configuración.

Has añadido tokens de refresco con la tabla tokens_refresco de la migración V6, que guarda el SHA-256 del token y no el token, con rotación en cada uso, detección de reutilización que revoca todas las sesiones del usuario ante la señal de robo y recarga de roles desde la base de datos en cada refresco. Y has mirado de frente los dos problemas que el marketing del JWT suele esconder: cerrar sesión en un mundo sin estado es revocar el refresco y aceptar hasta quince minutos de acceso vigente, o pagar con estado mediante una lista de revocación por jti; y el almacenamiento en el cliente, donde localStorage es el consejo más repetido y el peor, frente al llavero del sistema en la app móvil y la cookie HttpOnly; Secure; SameSite —con CSRF reactivado— en el panel web. El Swagger UI de 03-07 vuelve a funcionar con su botón Authorize, y conoces la alternativa madura para producción: spring-boot-starter-oauth2-resource-server con un proveedor de identidad que rota sus claves por JWKS y trae SSO y segundo factor de serie.

Queda un agujero, y es el mismo que dejamos anotado en 05-01 y en 05-03. Marta tiene un token válido con el rol ROLE_CIUDADANO, así que POST /api/v1/alquileres/9/finalizar pasa todas las reglas de la cadena: la ruta es legítima y el rol es correcto. Pero el alquiler número 9 es de otro ciudadano. Ninguna regla basada en URL puede expresar «solo tus propios alquileres», porque la respuesta no depende de la ruta ni del rol, sino del dato. Es el riesgo A01/BOLA del OWASP Top 10, el más explotado de las APIs REST. En 05-05, Seguridad a Nivel de Método y Endurecimiento de la API, bajaremos la seguridad hasta la capa de servicio con @EnableMethodSecurity, @PreAuthorize y expresiones SpEL, escribiremos un evaluador de permisos propio para la regla de los alquileres, y cerraremos el módulo endureciendo la API entera: CORS por entorno, limitación de tasa, HTTPS obligatorio, ocultación de la documentación en producción, auditoría de eventos de seguridad, revisión de dependencias vulnerables y una lista de comprobación antes de producción.