Spring SecurityJWTSecurityJava

JWT con Spring Security: decisiones, límites y errores reales

JWT no elimina los problemas de seguridad ni convierte una API en stateless por sí solo. Reviso autenticación, autorización, expiración, almacenamiento y revocación con criterios aplicados.

Edgar Camberos
Edgar Camberos
25 jul 202610 min de lectura

Código y evidencia relacionada

Enlaces directos a implementaciones, repositorios o recursos desplegados.

Qué resuelve JWT

JWT permite que una API valide un documento firmado sin consultar una sesión central en cada solicitud. Eso facilita ejecutar varias instancias, pero no elimina la necesidad de consultar usuarios, permisos o estados cuando la regla del negocio lo exige.

Flujo de autenticación

textedgar.dev
1. El cliente envía credenciales por HTTPS.
2. Spring Security autentica mediante PasswordEncoder y UserDetailsService.
3. La API emite un access token con expiración corta.
4. Un filtro valida firma, issuer, audience y expiración.
5. El contexto de seguridad recibe una identidad autenticada.
6. La autorización evalúa rol, propiedad y estado del recurso.

Autenticación no es autorización

Que un token incluya ROLE_ADMIN no significa que cualquier operación administrativa sea válida. En INCACORE, además del rol, una operación puede depender del recurso y de la responsabilidad del usuario.

Las reglas críticas deben vivir en servicios o políticas de dominio, no solamente en requestMatchers.

Dónde guardar el token

No existe una opción universal:

  • Cookie httpOnly: reduce exposición directa ante JavaScript, pero exige protección CSRF y configuración correcta de SameSite, Secure y dominio.
  • Memoria del cliente + Authorization header: reduce persistencia, pero el token se pierde al recargar y una vulnerabilidad XSS puede usarlo mientras la sesión está activa.
  • localStorage: es simple, pero aumenta el impacto de XSS porque cualquier script ejecutado en el origen puede leer el token.
  • La elección depende del tipo de cliente, arquitectura y amenazas, no de una regla aislada.

    Expiración y revocación

    Un access token debe expirar. Cuando el producto necesita sesiones largas, prefiero separar:

  • Access token breve.
  • Refresh token con rotación.
  • Registro de sesiones o familias de refresh tokens.
  • Revocación ante cambio de contraseña, cierre de sesión o actividad sospechosa.
  • Esto introduce estado controlado, pero permite responder a incidentes. Stateless no debe convertirse en una excusa para no poder revocar acceso.

    Claims mínimos

    Incluyo solo información necesaria para identificar y autorizar. Evito datos sensibles, perfiles completos o información que cambia con frecuencia.

    También valido issuer, audience, algoritmo esperado y timestamps. Aceptar cualquier algoritmo o confiar ciegamente en claims del cliente rompe el modelo de seguridad.

    Conclusión

    JWT es una pieza de transporte de identidad. Una implementación segura depende de HTTPS, expiración, validación estricta, protección del almacenamiento, reglas de autorización y una estrategia de revocación acorde al riesgo.

    Edgar Camberos

    Java Backend Developer · Spring Boot