OAuth app access restrictions stop members and outside collaborators from authorizing OAuth apps to reach organization resources. Unapproved apps lose access to private repositories and hook deliveries. New organizations have them on by default, but an organization that never configured them lets any authorized app reach private data.
What changes when restrictions are on
- Members and outside collaborators cannot authorize OAuth apps for organization resources.
- Apps authorized earlier lose access when an owner first turns restrictions on. Apps owned by the organization keep theirs.
- Unapproved apps stop receiving hook deliveries from private repositories and cannot use the API to reach private organization resources.
- Owners can turn restrictions off at any time.
GitHub's page also says privileged OAuth apps can still be authorized and can still access organization data.
The approval flow
A member who wants an app asks for approval. Owners are notified of pending requests and decide. Owners can also choose whether outside collaborators may request access for unapproved OAuth apps and GitHub Apps.
After approval, the app gets access to organization resources and webhooks it created earlier resume. If you later remove access, those webhooks are disabled, not deleted. If you switch restrictions off and on again, previously approved apps regain access automatically, which is a trap if you toggle during testing.
Why this is worth ten minutes
An OAuth app authorized by one developer can read what that developer can read. If the organization never restricted apps, that includes private repositories. A convenient code review plug in or a link preview tool then holds standing access to source code, and its vendor becomes part of your supply chain without anyone deciding that.
Consent based phishing relies on the same path: a convincing app asks for permissions, a busy person clicks accept.
A checklist
- Open the organization settings and confirm restrictions are on.
- Review the list of approved apps. Remove any nobody can name.
- For each approved app, write down an owner, the data it reaches and a review date.
- Decide your rule for outside collaborator requests.
- Add the question to onboarding: do not authorize apps against the organization without asking.
Treat a new app request like a small vendor review. Who runs it, what does it read, and how would we remove it? Write the answers in the same place you keep your vendor list, so the app is reviewed again at renewal time rather than forgotten after the first approval.
Where Safeguard fits
Safeguard scans dependencies and builds an SBOM, and its policies and gates can block a pull request that adds a known-vulnerable package. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Are restrictions on by default?
GitHub says new organizations have them on by default. An organization that never set them up lets any authorized OAuth app reach private resources.
Do restrictions delete webhooks?
No. If access is removed, webhooks the app created are disabled, not deleted.
Sources
Last reviewed: 19 October 2026.
