# Login con Microsoft para WTC: cómo lo iba a abordar

**Fecha:** 7 de agosto de 2026
**Estado:** esperando respuesta de InsForge
**Afecta a:** `summit2026.wtcglobal.org` y `admin-summit.wtcglobal.org` (Women Technology Summit 2026)

---

## 1. Dónde quedó el tema

Cualquier persona con cuenta `@wtcglobal.org` que elige "Continuar con Microsoft 365"
queda bloqueada. Después de seleccionar su cuenta, Microsoft corta con:

```
AADSTS700016: Application with identifier '54e8a1e4-2801-45bb-9dfb-0202fbcc1feb'
was not found in the directory 'ad2ebe3e-3cbf-40d9-98aa-81c7041a1214'.
```

**La causa está probada, no supuesta.** Consulté los cuatro extremos de
autenticación de Microsoft con ese identificador de aplicación:

| Extremo consultado | Resultado |
|---|---|
| Cuentas personales de Microsoft (`/consumers`) | La acepta y redirige a `login.live.com` |
| Cualquier directorio organizativo (`/organizations`) | `AADSTS700016` |
| Directorio de `wtcglobal.org` | `AADSTS700016` |
| **Consentimiento de administrador sobre ese directorio** | `AADSTS700016` |

El último renglón es el que cierra el asunto. La dirección de `/adminconsent`
existe precisamente para instalar una aplicación multiinquilino en un directorio
ajeno: si la aplicación estuviera publicada para organizaciones, esa dirección la
habría instalado en el acto. Que devuelva `AADSTS700016` ejecutada por un
**Administrador global** significa que no hay aplicación que instalar.

**Conclusión:** la aplicación compartida de InsForge está registrada **solo para
cuentas personales de Microsoft**. Para el directorio de `wtcglobal.org` no
existe, así que no hay nada que aprobar.

### Lo que esto descarta

- No es un permiso que falte en el directorio de WTC.
- No es el rol de quien lo intenta.
- No es acceso condicional, ni políticas de consentimiento, ni asignación de usuarios.
- No lo arregla registrar una aplicación propia y dejarla ahí: el flujo sigue
  pidiendo la de InsForge.

---

## 2. Un error que cometí y conviene no repetir

La primera solicitud que redacté le pedía a la administración de `wtcglobal.org`
que diera **consentimiento de administrador** para esa aplicación. **Eso es
imposible**, y mandó a su administrador a buscar durante un rato algo que no
existe.

Ya está corregido en el documento de reemplazo, que retira la solicitud, explica
por qué con la tabla de arriba y pide disculpas por el tiempo perdido.

**La lección operativa:** antes de pedirle algo a la administración de un cliente,
probar contra los servidores del proveedor que ese algo es posible. Cuesta dos
minutos y evita quemar credibilidad ajena.

---

## 3. Qué se le pidió a InsForge

Reporte enviado por el canal oficial del CLI.
**Id de seguimiento: `b04cc25b-e04f-4be4-818b-312212cf057c`.**
Correos, tokens y claves se redactaron antes de enviarlo.

Contenido, resumido:

1. **El arreglo principal.** Cambiar los "supported account types" de su registro
   `54e8a1e4-2801-45bb-9dfb-0202fbcc1feb` a *"Accounts in any organizational
   directory (multitenant) and personal Microsoft accounts"*. Con eso se destraba
   **para todos sus clientes**, no solo para nosotros: hoy ningún usuario de
   Microsoft 365 con cuenta de trabajo puede entrar en ninguna aplicación
   construida sobre InsForge.
2. **La advertencia que les ahorra el siguiente ticket.** Multiinquilino sin
   editor verificado sigue bloqueando el consentimiento de usuario final. O
   completan la verificación (MPN), o cada inquilino va a necesitar consentimiento
   de administrador una vez. Con la aplicación publicada para organizaciones, esa
   dirección de consentimiento **sí** va a funcionar, cosa que hoy no pasa.
3. **Credenciales propias por proyecto.** Que permitan configurar un `client_id` y
   `client_secret` propios de Microsoft. Hoy no existe: `insforge config export`
   muestra `[auth]`, `[auth.password]`, `[auth.smtp]` y ninguna sección de
   proveedores OAuth.
4. **Documentar la limitación.** El error crudo se lee como si el directorio del
   *cliente* estuviera mal configurado, y por eso mandó a depurar el inquilino
   equivocado. Una línea en la documentación de auth diciendo qué tipos de cuenta
   soporta la aplicación compartida habría evitado todo el desvío.

---

## 4. El plan según lo que respondan

### Escenario A — publican la aplicación para organizaciones

**Es el mejor caso y no requiere nada de WTC.**

1. Verificar el cambio antes de avisarle a nadie: repetir la consulta al extremo
   `/organizations` con ese `client_id`. Si el cambio se aplicó, deja de devolver
   `AADSTS700016`.
2. Probar el login real con una cuenta `@wtcglobal.org` en `summit2026.wtcglobal.org`.
3. **Si piden consentimiento de administrador**, recién ahí volver a la
   administración de WTC, esta vez con una solicitud que sí se puede cumplir:
   ```
   https://login.microsoftonline.com/ad2ebe3e-3cbf-40d9-98aa-81c7041a1214/adminconsent?client_id=54e8a1e4-2801-45bb-9dfb-0202fbcc1feb&redirect_uri=<la que InsForge indique>
   ```
   Con la aplicación ya publicada para organizaciones, esa dirección funciona.
4. Repetir para el **segundo directorio**: `wts.org.pe` es otro inquilino
   (`4afae270-3cc7-4328-9f00-6312c9fd9916`) y necesita su propio consentimiento.

### Escenario B — habilitan credenciales propias por proyecto

**Es el camino con más control y el que menos depende de ellos a futuro.**

La aplicación en el directorio de WTC ya existe, creada el 7 de agosto:

| Dato | Valor |
|---|---|
| Nombre para mostrar | `WTCGlobal` |
| Id. de aplicación (cliente) | `f15617bd-a8b6-426f-b7fe-cb7033567bfb` |
| Identificador de objeto | `3dc9e804-f57f-4c85-b860-91335addf18b` |
| Id. de directorio (inquilino) | `ad2ebe3e-3cbf-40d9-98aa-81c7041a1214` |

Le faltan tres cosas, y **una de ellas es bloqueante hoy**:

1. **Un secreto de cliente.** No tiene ninguno. En la vista general figura
   "Agregar un certificado o secreto", que es lo que Microsoft muestra cuando hay
   cero. Sin secreto, el intercambio del código por el token no se completa del
   lado del servidor y el login falla siempre.
   > Certificados y secretos → Nuevo secreto de cliente → copiar el **Valor** (no
   > el Id). Se muestra **una sola vez**. Transportarlo por un canal seguro, nunca
   > por correo en texto plano.
2. **Los tipos de cuenta correctos.** Hoy está en "Todos los usuarios de cuentas
   Microsoft", que trae el aviso de editor no verificado y no aporta nada si los
   que entran son cuentas de la organización.
   - Solo `@wtcglobal.org` → **"Solo las cuentas de este directorio organizativo"**.
   - También `wts.org.pe` → **"Cuentas en cualquier directorio organizativo"**, y
     entonces sí hace falta un consentimiento de administrador en ese segundo
     directorio, que esta vez funcionará porque la aplicación es de ellos.
3. **La URI de redirección.** Hay una registrada, pero **no sabemos cuál es la
   correcta para credenciales propias**. La de la aplicación compartida es
   `https://api.insforge.dev/auth/v1/shared/callback`; para credenciales propias
   la dirección puede ser distinta. **No tocarla hasta que InsForge la confirme.**

Permisos que la aplicación necesita, los cinco **delegados** (solo se ejercen
mientras una persona tiene la sesión iniciada, y con su alcance):

| Permiso | Qué habilita |
|---|---|
| `openid` | Iniciar sesión |
| `profile` | Ver el perfil básico (nombre, foto) |
| `email` | Ver la dirección de correo |
| `User.Read` | Leer el perfil del propio usuario que inició sesión |
| `offline_access` | Mantener la sesión sin volver a pedir credenciales |

No incluye lectura de correo, ni OneDrive, ni SharePoint, ni calendarios, ni
Teams, ni lectura del directorio, ni permisos de aplicación.

### Escenario C — dicen que no, o no responden en una semana

**El congreso no se detiene.** Google y el registro por correo cubren a todo el
mundo, incluido el personal de WTC con su correo corporativo.

Ahí la decisión pasa a ser de negocio, no técnica, y es tuya:

1. **Convivir con dos caminos de ingreso** y sacar "Continuar con Microsoft 365"
   de la pantalla para no ofrecer algo que falla. Cuesta un cambio de copy y
   elimina la frustración de quien lo intenta.
2. **Escalar con InsForge** apoyándose en que es un defecto que afecta a todos sus
   clientes empresariales, no un pedido a medida nuestro.
3. **Evaluar mover la autenticación** fuera de InsForge para este proyecto. Es la
   opción cara y solo tiene sentido si Microsoft 365 es un requisito del cliente y
   no una comodidad.

---

## 5. Mientras tanto: qué está vivo hoy

- **Google:** funciona.
- **Registro por correo:** funciona con cualquier correo, incluido el corporativo.
  Pide nombre, correo, código del evento y la autorización de datos.
- **Microsoft 365:** bloqueado, con la causa identificada y fuera de nuestro alcance.

**Recomendación para el evento:** si falta poco, avisarle al equipo de WTC que
entren con Google o con correo, y no dejar que descubran el bloqueo el día del
congreso.

---

## 6. Cómo verificar cada paso, sin depender de nadie

Estas comprobaciones se pueden correr en cualquier momento y no necesitan acceso
al directorio de WTC.

**¿Ya publicaron la aplicación para organizaciones?**

```bash
APP=54e8a1e4-2801-45bb-9dfb-0202fbcc1feb
RU=https%3A%2F%2Fapi.insforge.dev%2Fauth%2Fv1%2Fshared%2Fcallback
curl -s "https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?client_id=$APP&response_type=code&redirect_uri=$RU&scope=openid" \
  | grep -oE "AADSTS[0-9]+" | head -1
```

- Devuelve `AADSTS700016` → todavía no.
- No devuelve código de error → lo publicaron; pasar al escenario A.

**¿La aplicación existe en el directorio de WTC?**

En `entra.microsoft.com` → Aplicaciones empresariales → Todas las aplicaciones,
buscar `54e8a1e4-2801-45bb-9dfb-0202fbcc1feb`. Antes del consentimiento no
aparece; después, sí.

**La comprobación definitiva es siempre funcional:** entrar a
`summit2026.wtcglobal.org` con una cuenta `@wtcglobal.org` y elegir "Continuar
con Microsoft 365".

---

## 7. Seguimiento

| Cuándo | Qué hacer |
|---|---|
| A las 48 horas sin respuesta | Repetir la comprobación del extremo `/organizations`. Puede que lo hayan cambiado sin avisar. |
| A los 5 días sin respuesta | Escalar por otro canal, apuntando a que es un defecto que afecta a todos sus clientes empresariales. |
| Cuando respondan | Identificar el escenario (A, B o C) y ejecutar la sección correspondiente. |
| Antes de volver a pedirle algo al administrador de WTC | Probar contra los servidores de Microsoft que ese pedido es posible. |

---

## 8. Datos de referencia

| Dato | Valor |
|---|---|
| Aplicación de InsForge (la que el login usa) | `54e8a1e4-2801-45bb-9dfb-0202fbcc1feb` |
| Su URI de retorno | `https://api.insforge.dev/auth/v1/shared/callback` |
| Aplicación propia de WTC (registrada, sin usar) | `f15617bd-a8b6-426f-b7fe-cb7033567bfb` |
| Directorio de `wtcglobal.org` | `ad2ebe3e-3cbf-40d9-98aa-81c7041a1214` |
| Directorio de `wts.org.pe` | `4afae270-3cc7-4328-9f00-6312c9fd9916` |
| Reporte a InsForge | `b04cc25b-e04f-4be4-818b-312212cf057c` |
| Sitio del congreso | `https://summit2026.wtcglobal.org` |
| Panel interno | `https://admin-summit.wtcglobal.org` |

---

## 9. Lo que NO hay que hacer

- **No** volver a pedir consentimiento de administrador para
  `54e8a1e4-…` hasta que InsForge confirme que publicó la aplicación para
  organizaciones. Hoy no puede funcionar.
- **No** cambiar la URI de redirección de la aplicación propia de WTC hasta que
  InsForge confirme cuál corresponde para credenciales propias.
- **No** enviar el secreto de cliente por correo en texto plano.
- **No** presentar el bloqueo como un problema del directorio de WTC. No lo es, y
  su administración ya perdió tiempo por esa confusión.