Autenticación primaria con Google y Microsoft
Contexto
El TDR del servicio (tdr-cgbvp.md, sección Fase de desarrollo de componente de autenticación y acceso) establece:
Autenticación primaria: Integración con proveedores de identidad Google y Microsoft mediante OAuth2, utilizando las cuentas personales (Gmail, Outlook/Hotmail u otras de Microsoft) que los bomberos voluntarios ya poseen. La UTI no crea ni administra cuentas corporativas; únicamente lleva un registro de qué cuenta (correo) y qué número de celular usa cada bombero, de modo que solo las cuentas registradas por la UTI puedan completar el proceso. El número de celular registrado se utilizará como destino de los códigos de verificación del segundo factor de autenticación (2FA).
Esta sección documenta únicamente ese alcance. La autenticación secundaria (2FA por SMS mediante el gateway GSM institucional) es un requisito separado del TDR y tendrá su propia sección; aquí solo se menciona donde impacta el diseño de la autenticación primaria.
¿Qué significa este requisito?
Desglosado en decisiones concretas:
| Frase del TDR | Implicación técnica |
|---|---|
| "proveedores de identidad Google y Microsoft" | La aplicación no almacena contraseñas: delega la autenticación en Google y Microsoft como Identity Providers (IdP). |
| "mediante OAuth2" | Se usa OAuth 2.0 con OpenID Connect (OIDC), el estándar de la industria para login federado. |
| "cuentas personales que los bomberos ya poseen" | Se aceptan cuentas públicas (@gmail.com, @outlook.com, @hotmail.com, etc.). No hay directorio institucional. |
| "la UTI lleva un registro de qué cuenta usa cada bombero" | El control de acceso lo hace el sistema, no el IdP: tras el login, el backend verifica que el email esté en el registro autorizado por la UTI. El registro también incluye el número de celular de cada bombero, que será el destino del OTP challenge por SMS en el 2FA. |
Vista general para stakeholders
El sistema confía la verificación de la contraseña a Google y Microsoft, pero la autorización la decide el sistema consultando el registro de la UTI: solo los correos registrados pueden entrar.
¿Por qué cuentas personales + registro UTI?
- Sin infraestructura de identidad que crear: la Entidad no necesita Google Workspace ni Microsoft Entra ID; los bomberos usan la cuenta que ya tienen.
- Control sin administrar cuentas: la UTI no crea ni resetea contraseñas; solo mantiene la lista de correos autorizados (alta/baja de bomberos).
- Trazabilidad: cada acceso queda asociado al correo registrado del bombero.
Como cualquiera puede tener una cuenta Gmail u Outlook, el IdP ya no restringe quién puede intentar entrar. La barrera pasa a ser el registro de la UTI: el backend debe rechazar cualquier correo que no esté registrado, en cada login.
Audiencia de esta documentación
- Stakeholders: las secciones conceptuales y los diagramas explican qué se va a construir y qué se necesita de la Entidad.
- Programadores: las secciones técnicas describen el flujo OAuth2/OIDC, los claims a validar y la estrategia de pruebas.
Contenido de esta sección
- Proveedores de identidad: cómo funcionan Google y Microsoft como IdP.
- Requisitos para la UTI: qué se necesita de la Entidad.
- Decisiones de diseño: verificación contra el registro UTI, account linking, sesiones, errores y ambientes.
- Estrategia de pruebas: cómo probar con cuentas personales reales.
- Glosario: términos técnicos en inglés que se usan tal cual en todo el proyecto.