Decisiones de diseño
Puntos que el TDR no detalla y que este documento define para la implementación. Cada decisión indica su motivación y su impacto.
D1. Autorización contra el registro de la UTI
Decisión: el backend acepta cualquier cuenta Google o Microsoft válida, pero solo autoriza el acceso si el email del ID token está en el registro de correos autorizados por la UTI.
- Ya no se valida dominio (
hd) ni tenant (tid): las cuentas son personales. - La verificación es: firma del token +
iss/aud/exp+email_verified+ ¿el email está en el registro UTI? - El registro UTI incluye, además del correo, el número de celular de cada bombero; ese número será el destino del OTP challenge por SMS cuando se implemente el 2FA (ver D6).
Como cualquiera puede crear una cuenta Gmail u Outlook, el IdP no filtra nada. Si el registro de la UTI está desactualizado o vacío, el control de acceso se cae. La consulta al registro debe hacerse en cada login, no solo en el primero.
D2. Account linking (mismo correo en ambos IdP)
Escenario: un bombero registró [email protected] en la UTI. Si hoy entra con Google y mañana con Microsoft usando ese mismo correo, ¿es el mismo usuario?
Decisión: la identidad interna se resuelve por email normalizado a minúsculas. Ambos logins apuntan a la misma ficha de bombero. Se registra qué IdP usó en cada login para auditoría.
Alternativa considerada y descartada: usar iss + sub como identidad interna. Crearía dos cuentas distintas para la misma persona y, con ellas, fichas duplicadas. Se descarta porque el TDR exige unicidad de los datos personales.
D3. Sesión propia, no el ID token como sesión
Decisión: tras validar el ID token y el registro UTI, el backend crea una sesión propia (cookie HttpOnly; Secure; SameSite) con expiración corta y renovación controlada.
- El ID token de Google/Microsoft no se usa como token de sesión ni se expone al frontend más allá del intercambio inicial.
- Logout: cierra la sesión local. No se fuerza el logout del IdP (el bombero podría estar usando su correo personal en otra pestaña); se documenta como comportamiento esperado.
D4. Manejo de errores de login
| Caso | Comportamiento |
|---|---|
| Cuenta válida pero no registrada en la UTI | Mensaje: "Su correo no está registrado. Contacte a la UTI para darlo de alta" |
| Cuenta registrada pero dada de baja | Mismo mensaje + registro del intento en los logs de auditoría |
| El usuario cancela el login | Retorno a la pantalla de inicio sin mensaje alarmante |
| Falla técnica (red, IdP no disponible) | Mensaje genérico con opción de reintento; alerta a monitoreo |
D5. Ambientes dev / staging / prod
Decisión: cada ambiente tiene su propio client_id y client_secret, y sus propias redirect URIs, en ambos IdP.
- En dev el equipo usa sus propias apps y correos personales de prueba dados de alta en el registro.
- Staging y producción usan credenciales separadas y el registro UTI real.
D6. Relación con el 2FA (fuera de alcance, pero contemplado)
El TDR exige un segundo factor por SMS (OTP challenge mediante el gateway GSM institucional) después de la autenticación primaria.
Impacto en este diseño: el login OAuth2/OIDC no marca al usuario como plenamente autenticado, sino en estado PRIMARY_AUTH_OK. La sesión plena se activa solo tras verificar el OTP challenge. Así, cuando se implemente el 2FA, el flujo primario no se rediseña: simplemente se encadena.
Destino del SMS: el código de verificación se enviará al número de celular registrado por la UTI para ese correo, no a un número ingresado por el usuario en el login. Esto evita que alguien con una cuenta no registrada intente asociar un celular arbitrario, y es la razón por la que el registro de la UTI debe incluir el celular desde ahora.