如何在 Slack、GitHub 和 Microsoft 365 中审计第三方 OAuth 应用
要审计第三方 OAuth 应用，需分别检查各平台自身的授权列表：Slack 的 Installed Apps 页面、GitHub 的组织 OAuth 应用策略，以及 Microsoft Entra 的 Enterprise applications 列表。三者展示的是同一个底层问题的不同切面——哪些应用可以操作你的数据——但没有一个能同时展示另外两者的情况。
本指南给出每个平台的确切路径、其能展示的内容，以及单平台审计的局限所在。
如何在 Slack 中查看已授权的 OAuth 应用？
进入 Settings & administration → Manage apps，这会打开限定在你工作区范围内的 Slack Marketplace，然后在侧边栏顶部选择 Installed Apps。此功能在所有 Slack 套餐中均可使用，会列出每个已安装应用及其被批准的权限范围。
在 Enterprise Grid 中，管理仪表板的 Integrations 部分新增了一个跨所有工作区的全组织视图。这一跨工作区视图由 admin.apps:read 权限范围驱动，该范围仅限 Enterprise Grid 使用——即便如此，在同一次调用中也仅能显示哪些应用已批准、受限或待处理，并不会展示每个应用的完整权限范围列表。在单个工作区内，Installed Apps 页面仍是判断某应用实际能做什么的权威来源。
如何在 GitHub 中查看已授权的 OAuth 应用？
进入你的组织的 Settings → Third-party Access → OAuth app policy。新建组织默认开启 OAuth 应用访问限制，因此该页面同时也是成员申请新应用访问权限、以及所有者批准或拒绝申请的地方。要撤销此前已批准的应用，在同一列表中找到它并选择 Deny access。
GitHub Apps（与经典 OAuth Apps 不同的独立机制，大多数现代集成都采用它）需在另一处审查：组织的 Settings → Integrations → GitHub Apps（或 Installed GitHub Apps）会列出已安装的应用及每个应用可访问的仓库范围。
自 2026 年起，组织还可以通过 Settings → Third-party Access 对"谁有资格首先*申请*新应用"设置分级控制：成员和外部协作者均可申请应用（长期以来的默认设置）、可禁止外部协作者申请但仍允许成员申请、或阻止这两类用户申请任何应用——从而在申请到达所有者审批队列之前就收窄审计范围。组织级的 OAuth 应用访问限制本身也可以被完全关闭，这会取消所有成员的审批环节——在将 OAuth 应用策略列表视为已授权应用的完整记录之前，值得确认该限制是否仍处于开启状态。
如何在 Microsoft 365 中查看已授权的 OAuth 应用？
登录 Microsoft Entra 管理中心，进入 Identity → Applications → Enterprise applications → All applications。选择某个应用，然后点击 Permissions。Admin consent 标签页展示的是为整个租户授予的权限——可直接在此处撤销。User consent 标签页展示的是各用户为自己批准的权限——该门户并未为此提供撤销按钮；要收回该授权，需要具备 Cloud Application Administrator 角色的人员调用 Microsoft Graph API 或运行 PowerShell cmdlet。如果某租户彻底屏蔽了用户同意，全局管理员可改为开启管理员同意工作流，使被屏蔽的请求变为可审查的请求，而非陷入死路——具体审查队列如何运作，请参见 Microsoft 365 访问权限指南。
为什么单平台审计难以保持最新？
三个控制台，三种格式，甚至打开它们都需要三种不同的管理员角色。Slack 的全组织程序化视图需要 Enterprise Grid；Microsoft 的用户级授权需要 PowerShell 或 Graph，而非门户点击即可完成；GitHub 将经典 OAuth Apps 与 GitHub Apps 分为两个不同列表，管理员必须知道要分别检查。此外，Slack 自身的 Installed Apps 视图还分为 Approved、Restricted 和 Requests 三个标签页，因此一次完整的检查意味着要在三个平台之上再检查三种筛选条件。这三者都不会按风险对应用进行排序，也都不会告诉你同一供应商是否还在另外两个平台上以更广泛的权限连接着。
单平台列表无法告诉你什么，以及 8200.dev 如何解答
每个控制台只能告诉你该平台上已授权的内容。它们都无法展示综合全貌——同一个 AI 会议记录应用同时连接到 Slack 频道、某个 GitHub 仓库和某个 Microsoft 365 邮箱，且每处的权限范围都是单独授予的。8200.dev 的 Agent Guard 以最小权限、只读的方式读取全部三个平台——Slack 的 channels:read、groups:read、files:read、users:read 及相关只读权限范围，外加一次工作区配置审计；GitHub 的 read:org、只读仓库访问权限、read:user、安装清单、只读 Copilot 计费可见性，以及 read:audit_log；以及 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 和 DelegatedPermissionGrant.Read.All——并将来自三个平台的所有发现整合到一份按风险评分的清单中。Microsoft 365 连接器可与任何组织自有的 Microsoft 工作或学校目录配合使用，而非固定绑定单一租户，因此无论你的组织是唯一的目录还是众多目录之一，连接方式都相同。
上述所有权限范围均为只读。此处的任何操作都不会自动撤销某个应用的访问权限——那始终是留给组织自行审慎采纳的建议，或者是针对特定规则的明确自愿开启选项。
如需查看完整权限范围列表及各连接器扫描的具体内容，请参见 Slack、GitHub 和 Microsoft 365 连接器页面。