Estrategia de pruebas
Con cuentas personales, probar es más simple: no se necesita que la UTI provisione nada para empezar. El equipo usa sus propias cuentas Gmail/Outlook y las da de alta en el registro de prueba.
1. Apps propias de desarrollo (camino principal)
El equipo crea sus propios registros en ambas consolas:
| Proveedor | Recurso de prueba | Costo |
|---|---|---|
| Google Cloud project propio + consent screen External en modo "Testing" con los correos del equipo como usuarios de prueba | Gratuito | |
| Microsoft | App registration propio con "Supported account types" = personal + cualquier tenant (endpoint /common) | Gratuito |
Esto permite validar todo el flujo end-to-end (authorize → callback → intercambio del code → validación del ID token → consulta al registro → sesión) con cuentas personales reales del equipo.
El código no cambia entre dev y prod
Entre desarrollo y producción solo cambian valores de configuración (client_id, client_secret, redirect URIs) y el registro UTI usado. El flujo ya estará probado.
2. Matriz de casos de prueba
| # | Caso | Resultado esperado |
|---|---|---|
| P1 | Login con cuenta Google registrada en la UTI | Sesión creada |
| P2 | Login con cuenta Microsoft registrada en la UTI | Sesión creada |
| P3 | Login con cuenta válida pero no registrada | Rechazo: "correo no registrado" |
| P4 | Login con cuenta registrada pero dada de baja | Rechazo + log de auditoría |
| P5 | Mismo email por Google y por Microsoft | Misma identidad interna (account linking) |
| P6 | ID token expirado o manipulado | Rechazo por validación de firma o exp |
| P7 | El usuario cancela en la pantalla del IdP | Retorno limpio a la pantalla de inicio |
| P8 | Logout | Sesión local destruida; cookie invalidada |
| P9 | email_verified = false en el token | Rechazo |
| P10 | Estado PRIMARY_AUTH_OK sin 2FA | La sesión plena no se activa (preparación para D6) |
3. Mocks para pruebas automatizadas (CI)
Para la suite automatizada no se depende de Google ni Microsoft reales:
- Un mock OAuth2/OIDC server (o stubs de las respuestas del IdP) que emite ID tokens de prueba firmados con una clave de test.
- Permite probar en CI los casos P3 a P6 y P9 (rechazos y validaciones) de forma determinista.
- Las pruebas manuales con los IdP reales (P1, P2, P7, P8) se hacen contra las apps propias de desarrollo del §1.
4. Criterios de aceptación de esta fase
- Login end-to-end funcional con ambos IdP usando cuentas personales de prueba.
- Rechazo verificado de correos no registrados o dados de baja en el registro UTI.
- Account linking verificado con el mismo email en ambos IdP.
- Suite de CI verde con mocks del IdP.
- Registro UTI de prueba poblado (correos + números de celular) y proceso de alta/baja definido.