How to Audit Third-Party OAuth Apps Across Slack, GitHub and Microsoft 365

To audit third-party OAuth apps, check each platform's own authorization list separately: Slack's Installed Apps page, GitHub's organization OAuth app policy, and Microsoft Entra's Enterprise applications list. Each shows a different slice of the same underlying problem — which apps can act on your data — and none of them shows the other two.

This guide gives the exact path for each platform, what it shows, and where a per-platform audit runs out.

Where do I see authorized OAuth apps in Slack?

Go to Settings & administration → Manage apps, which opens the Slack Marketplace scoped to your workspace, then select Installed Apps at the top of the sidebar. This is available on every Slack plan and lists each installed app with the scopes it was approved for.

On Enterprise Grid, the admin dashboard's Integrations section adds an org-wide view across every workspace at once. That cross-workspace view is powered by the admin.apps:read scope, which is restricted to Enterprise Grid and — even there — only surfaces which apps are approved, restricted, or pending; it does not expose each app's full scope list in that same call. On a single workspace, the Installed Apps page remains the source of truth for what an app can actually do.

Where do I see authorized OAuth apps in GitHub?

Go to your organization's Settings → Third-party Access → OAuth app policy. New organizations have OAuth app access restrictions on by default, so this page is also where members request access to a new app and where an owner approves or denies it. To revoke a previously approved app, find it in the same list and select Deny access.

GitHub Apps (a separate mechanism from classic OAuth Apps, used by most modern integrations) are reviewed in a different place: organization Settings → Integrations → GitHub Apps (or Installed GitHub Apps) lists what's installed and which repositories each one can reach.

As of 2026, an organization can also set graduated controls over who is even allowed to *request* a new app in the first place, from Settings → Third-party Access: members and outside collaborators can both request apps (the long-standing default), outside collaborators can be blocked while members can still request, or both groups can be prevented from requesting any app at all — narrowing the audit surface before a request ever reaches an owner's queue. The organization-wide OAuth app access restriction itself can also be turned off entirely, which removes the approval step for every member — a setting worth confirming is still on before trusting the OAuth app policy list as a complete record of what has been authorized.

Where do I see authorized OAuth apps in Microsoft 365?

Sign in to the Microsoft Entra admin center and go to Identity → Applications → Enterprise applications → All applications. Select an app, then Permissions. The Admin consent tab shows permissions granted for the whole tenant — and can be revoked directly there. The User consent tab shows what individual users approved for themselves — and the portal does not offer a revoke button for it; taking it back requires a Microsoft Graph API call or a PowerShell cmdlet run by someone with the Cloud Application Administrator role. If a tenant blocks user consent outright, a Global Administrator can turn on an admin consent workflow instead, so a blocked request becomes a reviewable one rather than a dead end — see the Microsoft 365 access guide for exactly how that review queue works.

Why is a per-platform audit hard to keep current?

Three consoles, three formats, three different admin roles required to even open them. Slack's org-wide programmatic view needs Enterprise Grid; Microsoft's user-level grants need PowerShell or Graph, not a portal click; GitHub separates classic OAuth Apps from GitHub Apps as two different lists an admin has to know to check separately. Slack additionally splits its own Installed Apps view into Approved, Restricted, and Requests tabs, so a complete pass means checking three filters on top of the three platforms. None of the three ranks an app by risk, and none of them tells you whether the same vendor is also connected on the other two platforms with a broader set of permissions there.

What a per-platform list can't tell you, and how 8200.dev answers that

Each console tells you what's authorized on that one platform. None of them tells you the combined picture — the same AI note-taker connected to Slack channels, a GitHub repository, and a Microsoft 365 mailbox, each with its own separately-granted scope. 8200.dev's Agent Guard reads all three with least-privilege, read-only scopes — Slack's channels:read, groups:read, files:read, users:read and related read scopes plus a workspace configuration audit; GitHub's read:org, read-only repo access, read:user, installation inventory, read-only Copilot billing visibility, and read:audit_log; and Microsoft 365's 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 and DelegatedPermissionGrant.Read.All — and puts every finding from all three into one risk-scored inventory. The Microsoft 365 connector works with any organization's own Microsoft work or school directory, not a single fixed tenant, so it connects the same way whether your organization is the only one in the picture or one of several.

Every one of those scopes is read-only. Nothing here revokes an app's access on its own — that stays a recommendation an organization acts on deliberately, or an explicit opt-in for the specific rule it wants automated.

See the Slack, GitHub, and Microsoft 365 connector pages for the full scope list and what each one scans.