Apps de terceros en Google Workspace: quién controla el acceso
Si la app de un proveedor se registra en el directorio del cliente, este revoca el acceso desde su consola, tiene cuotas propias y conserva la auditoría.
En resumen
- Una aplicación de terceros puede conectarse a Google Workspace o Microsoft 365 de dos maneras: como aplicación pública del proveedor, a la que cada cliente da consentimiento, o registrada en el directorio del cliente y a su nombre.
- Con la aplicación registrada en el directorio del cliente, el consentimiento es un objeto de su consola de administración: el cliente revoca el acceso en el acto, sin escribirle al proveedor ni esperar que lo procese.
- En Google, las cuotas de las interfaces se asignan por proyecto: con una aplicación propia, el uso intensivo de otro cliente del mismo proveedor no puede consumir el cupo de su organización.
- La auditoría de accesos que registra la consola de Google o de Microsoft no depende de que el proveedor informe con fidelidad, y con aplicación propia cubre todo lo que el proveedor hace con esa integración.
- El costo del modelo recae en el equipo de sistemas del cliente, que tiene que registrar la aplicación y configurar la delegación una vez. Es la razón por la que la mayoría de los proveedores elige el modelo opuesto.
Una aplicación de terceros puede conectarse a Google Workspace o a Microsoft 365 como aplicación pública del proveedor, o registrada en el directorio del cliente y a su nombre. En el segundo modelo, el cliente controla el acceso: lo revoca desde su consola sin pedirle nada al proveedor, tiene cuotas propias y conserva la auditoría.
Es una decisión de arquitectura que casi nunca aparece en la conversación comercial y que determina buena parte de lo que la empresa va a poder hacer después. Una vez que la integración está andando, es cara de cambiar.
¿Qué diferencia hay entre una aplicación pública y una registrada en el directorio del cliente?
La diferencia es de quién es la aplicación, y por lo tanto de quién es la credencial.
Aplicación pública del proveedor. El proveedor registra una aplicación en su propia cuenta, la publica, y cada cliente que la contrata le concede consentimiento. Es el modelo por defecto del software como servicio, y tiene una virtud enorme para el proveedor: se configura una vez y sirve para todos los clientes.
Aplicación registrada en el directorio del cliente. La aplicación se crea dentro del directorio de la organización cliente, a nombre de la organización cliente. El proveedor recibe una credencial que sólo funciona contra ese directorio. El proceso se repite con cada cliente.
Desde afuera se ven idénticos: en los dos casos alguien acepta una pantalla de permisos y la integración empieza a funcionar. La diferencia aparece después, en tres momentos concretos:
| Aplicación pública del proveedor | Aplicación en el directorio del cliente | |
|---|---|---|
| Dónde vive la credencial | En la cuenta del proveedor, compartida entre clientes | En el directorio del cliente, sólo válida para él |
| Revocación | Posible desde la consola; la verificación de que cesó depende del proveedor | Unilateral e inmediata; la credencial revocada era la única |
| Cuotas de las interfaces | Compartidas entre los clientes de la misma aplicación | De la organización |
| Auditoría | La consola registra la actividad; el ciclo de vida de la credencial sólo lo ve el proveedor | La consola registra una aplicación y una credencial que son sólo de la organización |
| Trabajo de puesta en marcha | Mínimo para el cliente | Un registro de aplicación, una vez |
Igniten usa el segundo modelo para Google Workspace, Microsoft 365 y Slack. Por eso las credenciales de Google de su empresa nunca pasan por un proveedor que las comparta con otros: las contraseñas de sus usuarios no llegan a Igniten, y la credencial de la integración la genera su organización en su propio proyecto.
¿Cómo se revoca el acceso de una aplicación de terceros?
Con aplicación propia, desde la consola de administración de la organización, y el acceso cae en el acto. Es el punto principal; el resto son consecuencias.
El consentimiento que la empresa le dio a Igniten es un objeto que vive en su consola. Si mañana quiere cortar el acceso —porque terminó el contrato, porque hubo un incidente, porque cambió una política interna o porque quiere comprobar que puede—, entra a su consola y lo revoca. No hay que escribirle a nadie, ni esperar a que alguien procese un pedido de baja, ni existe una ventana en la que el acceso sigue vivo mientras se tramita algo.
Con una aplicación pública también se puede bloquear el acceso desde la consola. La diferencia está en qué lado queda la parte verificable: en el modelo público, confirmar que no quedó ninguna credencial viva depende de la infraestructura del proveedor. En el modelo de aplicación propia, la credencial revocada era la única que existía y estaba en el directorio del cliente.
¿Por qué importan las cuotas de las interfaces?
Porque son un recurso compartido que casi nadie discute al firmar. En Google, las cuotas de las interfaces se asignan por proyecto de Google Cloud. Si un proveedor atiende a muchos clientes sobre una misma aplicación pública, todos comparten el cupo de ese proyecto. Por ejemplo, un cliente que corre una reindexación masiva un lunes a la mañana puede hacer que las consultas de otro empiecen a recibir limitación por exceso de peticiones. Nada se rompe, pero el servicio se degrada, y la causa queda fuera del alcance de todos excepto del proveedor.
En Microsoft 365 una parte de los límites se calcula por aplicación y por organización, lo que atenúa el efecto. El principio es el mismo en los dos casos: con la aplicación en el directorio del cliente, ningún cupo depende del uso de otro cliente.
¿Dónde queda la auditoría?
Queda en la consola del cliente, generada por Google o por Microsoft y no por el proveedor. La consola de administración registra qué aplicación accedió a qué, cuándo y en nombre de quién. Con aplicación propia, esa es una vista completa de lo que el proveedor hizo con la integración.
Es la única forma de auditoría que no requiere confiar en que el proveedor reporte con fidelidad. Igniten entrega además su propio registro de accesos, escrito en almacenamiento con bloqueo de objeto que ni su cuenta administradora puede borrar, y exportable al sistema de vigilancia del cliente si lo pide. Con los dos registros, uno se contrasta contra el otro.
¿Qué pasa con las contraseñas y la credencial de la integración?
Son dos cosas distintas, y conviene separarlas:
- Las personas entran al panel de Igniten con usuario propio, contraseña y segundo factor obligatorio. En el plan Empresa, además, con identidad federada contra el proveedor corporativo: el proveedor de identidad autentica y Igniten no ve la contraseña. La identidad autentica pero no autoriza: los permisos se resuelven contra el padrón de Igniten.
- La integración usa una credencial que la organización genera en su propio proyecto y carga en el panel. Se guarda cifrada y es de sólo escritura: la interfaz de administración no tiene forma de devolverla, sólo muestra metadatos y los últimos cuatro caracteres. Revocarla en el directorio del cliente la vuelve inútil en el acto.
Qué permisos concede esa credencial, y con qué motivo cada uno, está en la lista de permisos recomendados, organizada en un nivel base de sólo lectura y un nivel de acción opcional. El criterio con que se arma esa lista está desarrollado en por qué le pedimos a los clientes el menor acceso posible.
¿Qué le cuesta al cliente registrar la aplicación en su directorio?
Le cuesta trabajo a su equipo de sistemas, una vez. Los pasos en Google Workspace son:
- Elegir o crear un proyecto de Google Cloud de la organización.
- Habilitar sólo las interfaces de las fuentes que se van a usar: Drive, Gmail, Calendar, Chat y el directorio.
- Crear la credencial de la integración y cargarla en el panel de Igniten.
- Autorizar la delegación a nivel de dominio con los alcances publicados.
- Acotar esa delegación al grupo de personas habilitadas, no al dominio entero.
En Microsoft 365 el equivalente es registrar la aplicación en el propio inquilino, dar el consentimiento de administrador y sumar una política de acceso a aplicaciones limitada a un grupo de buzones, que es el control que realmente acota el alcance.
El recorrido guiado de cada uno está en la integración con Google Workspace y en la integración con Microsoft 365, con el rol que hace falta para ejecutarlo. Reduce la fricción; no la elimina. En algunas organizaciones el registro implica un ticket y una aprobación interna, y esa espera es la razón por la que la mayoría de los proveedores elige el modelo público.
¿Por qué elegir una garantía verificable antes que una promesa?
Porque «no vamos a usar mal su acceso» y «usted puede cortarnos el acceso sin hablar con nosotros» son afirmaciones de naturaleza distinta. La primera es una promesa. La segunda es una propiedad del sistema y se comprueba en treinta segundos desde la consola.
Es el mismo criterio del principio de menor privilegio y de cualquier gobernanza de datos que involucre a un tercero: entre una garantía que depende de la conducta del proveedor y una que el cliente verifica solo, conviene la segunda. También reduce el vendor lock-in: una integración que el cliente controla es una integración de la que puede salir.
Si su equipo está evaluando cómo conectar un agente de IA a su suite corporativa, la documentación técnica de seguridad describe los demás mecanismos —cómo se separan los datos de una organización de los de otra, dónde vive la clave de cifrado, quién de Igniten puede ver qué—. La plataforma está en beta privada, y esa página describe sus controles en disponibilidad general. La otra decisión de diseño que limita al propio proveedor está en lo que decidimos no indexar, y el resto de las notas, en el tema de gobernanza de IA del blog.