Qué necesitamos de la UTI

Con el nuevo alcance (cuentas personales de los bomberos), la carga sobre la UTI se reduce drásticamente: ya no se necesita Google Workspace, Microsoft Entra ID, ni que la UTI cree cuentas. Las credenciales OAuth2 las crea el equipo de desarrollo en sus propias consolas. Esto es lo que sí se necesita.

1. Lo que la UTI debe proveer

#	Qué pedir	Detalle
1.1	Registro de bomberos autorizados (correo + celular)	La lista de qué cuenta (correo) usa cada bombero y su número de celular. El correo es la fuente de verdad para autorizar el acceso; el celular será el destino de los códigos SMS del 2FA (OTP challenge mediante el gateway GSM institucional).
1.2	Proceso de alta/baja de registros	Cómo y cuándo la UTI registra un correo y celular nuevos o da de baja uno (ej. cuando un bombero deja la institución), y cómo se actualiza un dato cuando el bombero cambia de correo o de número.
1.3	Canal para actualizar el registro	Cómo nos sincronizamos: ¿una tabla que la UTI edita? ¿un archivo? ¿un responsable al que pedir cambios?
1.4	Registros de prueba	2–3 correos (pueden ser personales del equipo) con sus números de celular, dados de alta en el registro para probar el flujo.

El registro es el nuevo "directorio"

Antes, la autorización la daba el directorio institucional (Workspace/Entra). Ahora la da el registro de la UTI (correo + celular). Sin ese registro poblado, nadie puede entrar al sistema; y sin el celular registrado, el 2FA por SMS no tendrá destino válido.

2. Lo que el equipo de desarrollo gestiona (ya no depende de la UTI)

Recurso	Quién lo crea	Detalle
Google Cloud project + OAuth Client ID	Equipo de desarrollo	Consent screen External; acepta cualquier cuenta Google
Microsoft app registration	Equipo de desarrollo	"Supported account types" = personal + cualquier tenant (endpoint /common)
client_id / client_secret	Equipo de desarrollo	Se guardan como secretos del backend, nunca en el repositorio
Redirect URIs	Equipo de desarrollo	Se registran en ambas consolas por ambiente

3. Información que nosotros debemos definir

• URLs de callback por ambiente, por ejemplo: https://<dominio-dev>/auth/callback/google y https://<dominio-dev>/auth/callback/microsoft.
• Dominios definitivos de staging y producción (cuando existan).
• Nombre visible de la aplicación en la pantalla de login (ej. "Sistema DIGEVO — CGBVP").

4. Ambientes y rotación de secretos

• Un juego de credenciales por ambiente (dev / staging / prod). Jamás reutilizar el client_secret de producción en desarrollo.
• Definir el proceso de rotación del client_secret: frecuencia, canal seguro y ventana de vigencia.
• Los client_secret se almacenan como secretos del backend (variables de entorno o vault), nunca en el repositorio.

5. Resumen ejecutivo

De la UTI solo necesitamos: (1) el registro de bomberos autorizados (correo personal + número de celular), (2) el proceso para mantenerlo actualizado, y (3) algunos registros de prueba dados de alta. Las credenciales OAuth2 de Google y Microsoft las crea y administra el equipo de desarrollo, porque las cuentas son personales y no requieren directorio institucional. El celular registrado se reserva para el 2FA por SMS exigido por el TDR.