Cómo auditar aplicaciones OAuth de terceros en Slack, GitHub y Microsoft 365

Para auditar aplicaciones OAuth de terceros, revise por separado la lista de autorizaciones propia de cada plataforma: la página de Aplicaciones Instaladas de Slack, la política de aplicaciones OAuth de la organización en GitHub, y la lista de aplicaciones empresariales de Microsoft Entra. Cada una muestra una parte distinta del mismo problema subyacente —qué aplicaciones pueden actuar sobre sus datos— y ninguna muestra las otras dos.

Esta guía ofrece la ruta exacta para cada plataforma, qué muestra y dónde se queda corta una auditoría por plataforma.

¿Dónde veo las aplicaciones OAuth autorizadas en Slack?

Vaya a Settings & administration → Manage apps, lo cual abre el Slack Marketplace acotado a su espacio de trabajo, y luego seleccione Installed Apps en la parte superior de la barra lateral. Esto está disponible en todos los planes de Slack y muestra cada aplicación instalada junto con los alcances (scopes) para los que fue aprobada.

En Enterprise Grid, la sección Integrations del panel de administración añade una vista a nivel de toda la organización que abarca todos los espacios de trabajo a la vez. Esa vista entre espacios de trabajo se basa en el scope admin.apps:read, restringido a Enterprise Grid y que —incluso ahí— solo muestra qué aplicaciones están aprobadas, restringidas o pendientes; no expone la lista completa de scopes de cada aplicación en esa misma llamada. En un solo espacio de trabajo, la página Installed Apps sigue siendo la fuente de verdad sobre lo que una aplicación puede hacer realmente.

¿Dónde veo las aplicaciones OAuth autorizadas en GitHub?

Vaya a Settings → Third-party Access → OAuth app policy de su organización. Las organizaciones nuevas tienen activadas por defecto las restricciones de acceso a aplicaciones OAuth, por lo que esta página es también donde los miembros solicitan acceso a una nueva aplicación y donde un propietario la aprueba o deniega. Para revocar una aplicación previamente aprobada, búsquela en la misma lista y seleccione Deny access.

Las GitHub Apps (un mecanismo distinto de las OAuth Apps clásicas, usado por la mayoría de las integraciones modernas) se revisan en otro lugar: Settings → Integrations → GitHub Apps (o Installed GitHub Apps) de la organización muestra lo que está instalado y a qué repositorios puede acceder cada una.

A partir de 2026, una organización también puede establecer controles graduados sobre quién está siquiera autorizado a *solicitar* una nueva aplicación en primer lugar, desde Settings → Third-party Access: tanto los miembros como los colaboradores externos pueden solicitar aplicaciones (el valor predeterminado de siempre), se puede bloquear a los colaboradores externos mientras los miembros aún pueden solicitar, o se puede impedir que ambos grupos soliciten cualquier aplicación —lo que reduce la superficie de auditoría antes de que una solicitud llegue siquiera a la cola de un propietario. La restricción de acceso a aplicaciones OAuth de toda la organización también se puede desactivar por completo, lo que elimina el paso de aprobación para todos los miembros—un ajuste que vale la pena confirmar que sigue activo antes de confiar en la lista de la política de aplicaciones OAuth como un registro completo de lo que se ha autorizado.

¿Dónde veo las aplicaciones OAuth autorizadas en Microsoft 365?

Inicie sesión en el Microsoft Entra admin center y vaya a Identity → Applications → Enterprise applications → All applications. Seleccione una aplicación y luego Permissions. La pestaña Admin consent muestra los permisos concedidos para todo el inquilino (tenant) —y se pueden revocar directamente ahí. La pestaña User consent muestra lo que los usuarios individuales aprobaron por sí mismos —y el portal no ofrece un botón de revocación para ello; retirarlo requiere una llamada a la API de Microsoft Graph o un cmdlet de PowerShell ejecutado por alguien con el rol de Cloud Application Administrator. Si un inquilino bloquea por completo el consentimiento del usuario, un Administrador Global puede activar en su lugar un flujo de trabajo de consentimiento del administrador, de modo que una solicitud bloqueada se convierta en algo revisable en lugar de un callejón sin salida—consulte la guía de acceso a Microsoft 365 para ver exactamente cómo funciona esa cola de revisión.

¿Por qué es difícil mantener actualizada una auditoría por plataforma?

Tres consolas, tres formatos, tres roles de administrador distintos solo para poder abrirlas. La vista programática de Slack a nivel de organización requiere Enterprise Grid; las concesiones a nivel de usuario de Microsoft necesitan PowerShell o Graph, no un clic en el portal; GitHub separa las OAuth Apps clásicas de las GitHub Apps como dos listas distintas que un administrador debe saber revisar por separado. Slack, además, divide su propia vista de Installed Apps en las pestañas Approved, Restricted y Requests, de modo que una revisión completa implica comprobar tres filtros además de las tres plataformas. Ninguna de las tres clasifica una aplicación por nivel de riesgo, y ninguna le indica si el mismo proveedor también está conectado en las otras dos plataformas con un conjunto más amplio de permisos ahí.

Qué no puede decirle una lista por plataforma, y cómo lo resuelve 8200.dev

Cada consola le indica qué está autorizado en esa plataforma en particular. Ninguna le muestra la imagen combinada: el mismo asistente de notas con IA conectado a canales de Slack, un repositorio de GitHub y un buzón de Microsoft 365, cada uno con su propio conjunto de scopes concedido por separado. Agent Guard de 8200.dev lee las tres con scopes de solo lectura y mínimo privilegio —de Slack, channels:read, groups:read, files:read, users:read y otros scopes de lectura relacionados, además de una auditoría de la configuración del espacio de trabajo; de GitHub, read:org, acceso de solo lectura a repositorios, read:user, inventario de instalaciones, visibilidad de solo lectura de la facturación de Copilot, y read:audit_log; y de Microsoft 365, Sites.Read.All, Files.Read.All, Directory.Read.All, Application.Read.All, User.Read.All, Policy.Read.All, Reports.Read.All, AuditLog.Read.All, RoleManagement.Read.Directory y DelegatedPermissionGrant.Read.All— y reúne todos los hallazgos de las tres en un único inventario con puntuación de riesgo. El conector de Microsoft 365 funciona con el directorio de trabajo o educativo propio de cualquier organización de Microsoft, no con un único inquilino fijo, por lo que se conecta de la misma manera tanto si su organización es la única involucrada como si es una entre varias.

Todos esos scopes son de solo lectura. Nada de esto revoca por sí solo el acceso de una aplicación —eso sigue siendo una recomendación que la organización decide llevar a cabo de forma deliberada, o una activación explícita para la regla específica que se desee automatizar.

Consulte las páginas de los conectores de Slack, GitHub y Microsoft 365 para ver la lista completa de scopes y qué analiza cada uno.