Seguridad aplicada en el proyecto

Decisiones técnicas.

Decidimos optar por usar un token para la autenticación y autorización en la página.

Dependencias utilizada

JJWT JJWT es la librería de Java para trabajar con tokens JWT (JSON Web Tokens). En el ecosistema de Spring Boot, normalmente se usa para crear, firmar, leer y validar tokens de autenticación de forma segura.

Lo que hicimos fue integrarlo dentro de la seguridad de Spring Security con JWT como mecanismo de autenticación para recursos protegidos.

OAuth2 Resource Server Es una dependencia que habilita la validación de tokens JWT para proteger endpoints de la API.

Aplicación en el proyecto

Oauth2: Decide si una app o usuario tiene permiso para acceder a un recurso JWT: Formato del token con la información del usuario y sus permisos Spring Security (con Oauth2): Valida el token y protege la API

Cuando un usuario se autentica, el backend crea un JWT con su nombre de usuario y sus permisos. Ese token lleva una fecha de emisión y una fecha de expiración. La firma se hace con una clave secreta y con algoritmo HMAC SHA-512. Cuando llega una petición protegida, Spring Security valida la firma y extrae la información del token. A partir de ahí, convierte esos roles en permisos de seguridad para decidir si permite la petición. La generación del token se hace en TokenService.java. Allí se construye el contenido del token con el usuario autenticado, la fecha de emisión, la expiración y los roles. Esos roles se insertan como claim del token para que después la aplicación pueda realizar la autorización.

¿Por qué es importante? Porque permite que la aplicación sea stateless: el servidor no necesita guardar la sesión en memoria o en base de datos para cada usuario. Basta con confiar en el token que el cliente envía en cada petición. Eso hace que la API sea más simple, escalable y adecuada para entornos web modernos.

En otras palabras:

• Spring Security gestiona la seguridad
• El backend genera un token al iniciar sesión
• El token incluye la identidad del usuario y sus roles
• Cada petición protegida valida ese token con la clave secreta del servidor
• según los roles incluidos en el token, el sistema autoriza o deniega acceso a rutas concretas
• Esto se configura principalmente en SecurityConfig.java.

Capas de seguridad adicionales.

• Por petición del cliente. Añadimos una feature para que, los usuarios Admin que inicien sesión por primera vez, tengan que cambiar obligatoriamente su contraseña.

Aparte de la lógica, conseguimos implementar esto modificando la migracion de la tabla de autorización de usuarios añadiendole un campo booleano (true, debe cambiar la contraseña | false, no necesita este recurso) para que una vez haya realizado la modificación vuelva a pasar a false.

PipeLine de llamadas