Configurar proveedores de identidad

Control de acceso explica qué hace un proveedor. Esta página es el cableado: los valores exactos que pide cada proveedor y dónde encontrarlos.

La URI de redirección va primero

Todos los proveedores, sin excepción, necesitan un valor registrado de su lado: la URL a la que devuelven al usuario tras iniciar sesión.

El panel muestra el valor exacto en cada proveedor que abras, en Acceso → Inicio de sesión, con un botón de copiar. Úsalo: no lo escribas a mano.

Microsoft — cuentas de trabajo o centro educativo

Usa el proveedor Entra ID. Cubre las cuentas que viven en un directorio de Microsoft (tu@tu-empresa.com), no las direcciones personales de Outlook o Hotmail.

1. En el portal de Azure, ve a Microsoft Entra ID → Registros de aplicaciones → Nuevo registro.
2. En URI de redirección, elige Web y pega la URL de callback del panel.
3. Copia el ID de aplicación (cliente) y el ID de directorio (inquilino) de la página de información general.
4. En Certificados y secretos → Nuevo secreto de cliente, crea un secreto y copia su valor al momento: Azure no vuelve a mostrarlo.
5. En ConnXL, añade el proveedor Entra, pega el ID de cliente y el de inquilino, y apunta el secreto de cliente a tu propio almacén de secretos.

Quién puede iniciar sesión es una elección aparte en ese proveedor:

• Solo mi organización de Microsoft — el emisor queda fijado a tu inquilino. A cualquiera de fuera se le rechaza antes de comprobar ninguna otra regla.
• Cualquier organización de Microsoft — acepta directorios de otras empresas, sujeto a tus reglas de audiencia. Requiere dos cosas en tu registro de aplicación que ConnXL no puede configurar ni detectar: el registro debe aceptar cuentas de cualquier directorio organizacional (multi-tenant), y debe pedir el claim opcional xms_edov en el token de acceso (Configuración de token → Agregar claim opcional). Sin lo primero, Microsoft rechaza por su cuenta los inicios de sesión externos; sin lo segundo, se rechaza cada inicio de sesión de nuestro lado, porque ese claim es la única señal de que un email pertenece realmente a quien lo presenta.

Microsoft — cuentas personales

Usa el proveedor Cuenta personal de Microsoft para direcciones de outlook.com, hotmail.com y live.com. No están en ningún directorio de Entra, así que el proveedor Entra nunca las aceptará.

La configuración es igual que arriba con una diferencia: en Nuevo registro, elige como tipos de cuenta admitidos Solo cuentas personales de Microsoft (o «cualquier directorio organizacional y cuentas personales de Microsoft» si quieres ambas poblaciones). No hay emisor que introducir: todas las cuentas personales de Microsoft viven en un único directorio propiedad de Microsoft, así que ConnXL fija ese emisor por ti.

Microsoft — cualquier cuenta

Usa el proveedor Microsoft (cualquier cuenta) cuando tus usuarios son una mezcla de directorios de trabajo/escuela y cuentas personales, y quieres un único botón de inicio de sesión para todos. No hay tenant ni emisor que introducir: el inicio de sesión pasa por el endpoint common de Microsoft, y ConnXL verifica el emisor de cada token contra el tenant en el que ese mismo token fue emitido.

La configuración es el mismo registro de aplicación de arriba, con dos ajustes que son ambos obligatorios (ConnXL no puede establecer ni detectar ninguno, y equivocarse en uno falla como un error opaco de Microsoft):

1. En Nuevo registro (o después en Autenticación → Tipos de cuenta admitidos), elige Cuentas en cualquier directorio organizativo y cuentas personales de Microsoft. Cualquier opción más estrecha hace que la propia Microsoft rechace una de las dos clases de cuenta.
2. En Configuración de token → Agregar notificación opcional → ID, añade xms_edov. Los emails de cuentas de trabajo solo se aceptan cuando Microsoft atestigua el propietario del dominio; sin la notificación, todo inicio de sesión con cuenta de trabajo se rechaza en nuestro lado (las cuentas personales no se ven afectadas: su dirección es la identidad verificada de la cuenta).

Google

Usa el proveedor Google. No hay emisor que introducir: Google tiene exactamente uno, compartido por todas las cuentas de Google.

1. En la consola de Google Cloud, ve a APIs y servicios → Credenciales → Crear credenciales → ID de cliente de OAuth.
2. Tipo de aplicación Aplicación web; añade la URL de callback en URIs de redirección autorizados.
3. Copia el ID de cliente y el secreto de cliente.

El equivalente a la elección «quién puede iniciar sesión» de Microsoft vive del lado de Google, en Pantalla de consentimiento de OAuth → Tipo de usuario:

• Interno — solo cuentas de tu organización de Google Workspace.
• Externo — cualquier cuenta de Google de internet. Mientras la app esté en Pruebas tienes un tope de 100 usuarios de prueba nombrados; publicarla lo elimina.

Cualquier otro proveedor (OIDC genérico)

Usa el proveedor OpenID Connect para todo lo demás. No tiene límite: conecta Okta y Auth0 y tu propio Keycloak a la vez, cada uno con su botón de inicio de sesión.

Necesita tres cosas: la URL del emisor, un ID de cliente y un secreto de cliente. ConnXL lee el documento /.well-known/openid-configuration del emisor para descubrir los endpoints de autorización, token y JWKS, así que nunca los introduces.

El emisor debe ser una URL https:// con host: un dominio a secas se rechaza. El selector Configurar para, junto al campo, cambia el ejemplo a la forma de tu proveedor:

Cualquier otro proveedor que cumpla el estándar funciona igual: si publica un documento de descubrimiento, ConnXL puede usarlo.

Ámbitos

Deja la lista de ámbitos vacía salvo que tu proveedor necesite más que los predeterminados. ConnXL siempre pide lo necesario para identificar al usuario; los ámbitos extra solo sirven cuando tu IdP exige uno explícito para entregar el claim del email.

Seguridad a nivel de fila (intercambio de token)

Todo lo anterior sirve para que alguien inicie sesión. Esta sección va de lo que pasa después: llevar esa identidad hasta tu propia base de datos, para que una consulta devuelva sus filas y las de nadie más.

El modo de autenticación Intercambio de token de inicio de sesión de una conexión HTTP lo hace posible. En lugar de reenviar el token de Microsoft tal cual, el agente emite un JWT de vida corta a partir de la identidad que acaba de validar, lo firma con un secreto que aportas tú, y lo envía como bearer token en cada petición que hace la función.

El token emitido lleva sub, email y name del usuario de Excel con la sesión iniciada, más role, aud, iss, iat y exp. PostgREST —la API REST que Supabase genera sobre tu base de datos— y Hasura aceptan exactamente esa forma, así que tus políticas de Row-Level Security se aplican por usuario: cada petición desde una celda llega como la persona que escribió la fórmula, no como una única cuenta de servicio compartida.

Cuál de los dos modos de usuario elegir

• user_token — reenvío directo. Elígelo cuando tu API valida los tokens de Microsoft por sí misma: ya tiene configurados el emisor, la audiencia y las claves de firma, y lee la identidad de quien llama directamente del token que reenvía el agente.
• user_token_exchange — intercambio de token. Elígelo cuando tu API valida sus propios JWT y no sabe nada de Microsoft: PostgREST, Supabase, Hasura o cualquier servicio que verifique un secreto HS256 compartido. El agente es el puente entre ambos mundos.
• Ambos modos envían la credencial como Authorization: Bearer <token>. Si tu API la lee de otra cabecera, pon ese nombre en el campo userTokenHeader de la conexión: el token se envía entonces sin prefijo en esa cabecera. Déjalo vacío para el comportamiento por defecto.

Receta: filas por usuario desde Supabase

1. Localiza el secreto de firma. En tu panel de Supabase, ve a Project Settings → API → JWT Secret. Ese es el secreto con el que PostgREST verifica cada token que le llega.
2. Guárdalo como referencia. Pon el valor en tu propio almacén de secretos y apunta a él el campo exchangeSecret de la conexión — secret://env/SUPABASE_JWT_SECRET, o cualquiera de los demás backends que se listan en Conexiones. El valor en sí nunca llega a ConnXL.
3. Crea la conexión. Tipo HTTP API, URL base https://<project-ref>.supabase.co/rest/v1, autenticación Intercambio de token de inicio de sesión, audiencia authenticated.
4. Añade la cabecera apikey. PostgREST quiere la anon key de tu proyecto en cada petición además del bearer token. Añádela como cabecera extra en la conexión — nombre apikey, valor la anon key, de nuevo como referencia secret://. Sin ella Supabase rechaza la llamada antes siquiera de mirar el JWT.
5. Escribe la política. Activa RLS en la tabla y ánclala a un claim del token emitido:

create policy "own rows" on documents for select using (auth.jwt()->>'sub' = user_id);

Usa auth.jwt()->>'email' en su lugar cuando tus filas se identifiquen por dirección de correo y no por el subject id del proveedor.

Los campos del intercambio

Cuando el inicio de sesión no funciona

• «redirect_uri mismatch» — la URL registrada no coincide con la que muestra el panel, carácter por carácter. Cópiala de nuevo.
• «redirect_uri mismatch» que se queja de http:// frente a https:// (Entra lo muestra como AADSTS500112) — el TLS termina en un balanceador de carga o proxy inverso delante del agente, y el agente no confía en las cabeceras reenviadas por defecto. Define CONNXL_TRUSTED_PROXY=1 en el host del agente para que el callback se construya como https://.
• El inicio de sesión funciona pero el complemento igual te rechaza — la autenticación funcionó, la autorización no. Revisa los dominios permitidos/denegados y la audiencia en Control de acceso.
• Todos los inicios de sesión de Entra fallan en modo «cualquier organización» — falta el claim opcional xms_edov en el registro de aplicación.
• No pasa nada al pulsar el botón de inicio de sesión — el agente debe servir HTTPS de confianza; Excel se niega a cargar un complemento, o su diálogo de inicio de sesión, desde un host no confiable.