How do I see which OAuth apps can reach my GitHub org?

Organization owners can see third-party apps in the org settings, turn on OAuth app access restrictions so unapproved apps lose access, and review app activity in the audit log. Start with restrictions, because without them any OAuth app a member authorizes can also reach your private resources.

Why this is a shadow IT question

A developer who clicks "Authorize" on a nice-looking tool has just created a connection between that tool and your code. Nobody in security saw it, no ticket exists, and the app may hold a token for as long as the member keeps it. That is shadow IT in its most common engineering form.

GitHub's documentation says it plainly: when restrictions are not enabled, any OAuth app authorized by an organization member can also access the organization's private resources.

What restrictions change

When OAuth app access restrictions are on, apps that are not approved lose access to organization resources, including API access to private organization data. Members and outside collaborators cannot authorize OAuth app access to organization resources on their own. They can ask an owner to approve an app, and owners receive a notification of pending requests.

GitHub also states that new organizations have these restrictions enabled by default. Older organizations may differ, so check rather than assume. One exception to know about: privileged OAuth apps can still be authorized by users and used to access organization data.

Steps to review your org

1. As an organization owner, open the organization settings and find the third-party access section for OAuth apps.
2. Note whether restrictions are enabled. If they are off, write down how many apps are currently authorized before you change anything.
3. For each app, record the vendor, the owner of the request, what it is used for, and when it was approved.
4. Deny anything with no clear owner or purpose. Expect a few complaints and treat them as useful information about unmet needs.
5. Turn restrictions on. Decide whether outside collaborators may request access for unapproved apps.
6. Repeat the review on a schedule. A quarterly rhythm is a reasonable start for a mid-sized org.

GitHub Apps are a related but separate surface, with their own installation review. Covering both is worth the extra ten minutes. For the permission questions that come with an installed app, see review GitHub App permissions before installing.

Use the audit log to see what changed

The organization audit log records app activity, including integration installations, installation requests, OAuth application events and webhook events. Only organization owners can open it. Events are kept for 180 days, and by default only the past three months are shown, so use a date range for older events. You search with qualifiers such as actor, action, repo and created, and you can export filtered results as JSON or CSV.

A useful first query is installation requests, because it shows what your members have been trying to connect, whether or not you approved it.

Do not stop at GitHub

The same pattern exists in your identity provider and your chat and ticketing tools. Your source host is the highest value place to start, since it holds the code. For the identity side, see how to find third-party apps with access to your Google Workspace data.

Quick check

Safeguard's asset discovery and policy features can help you keep a list of approved integrations next to your dependency data. A free scan is available at gold.safeguard.sh/scan.

Sources

• GitHub Docs: About OAuth app access restrictions
• GitHub Docs: Reviewing the audit log for your organization

Last reviewed: 19 October 2026.