What is the difference between OAuth apps and GitHub Apps for repository access control?

OAuth apps are user-authorized integrations that can be harder to govern at the organization level, while GitHub Apps provide more granular control over permissions and repository access. For security teams, that difference matters because finer-grained access usually reduces standing exposure, simplifies policy enforcement, and limits the blast radius if an integration is abused.

How OAuth apps and GitHub Apps differ in access model

OAuth apps are usually authorized by a user and then operate with that user’s granted scopes, which makes them flexible but less precise for repository governance. GitHub Apps are installed on an organisation or repository and request explicit, narrower permissions, so access can be scoped more cleanly to the exact repositories and actions the integration needs.

The practical difference is not just “who signs in”, it is how the integration is governed over time. OAuth consent often reflects a one-time user decision, while GitHub App permissions are structured around installation, repository selection and per-feature access. That makes GitHub Apps easier to reason about when you want least privilege and clear ownership.

For repository access control, the key question is whether the integration should inherit a user’s broader authority or hold its own bounded set of permissions. A GitHub App is usually the better fit when you need to limit blast radius, separate duties, or avoid tying automation to a person’s standing access. OAuth apps still have legitimate uses, but they are usually a weaker fit for tightly governed repository access.

Why governance and blast radius are different

With OAuth apps, the main risk is that the integration can become broader than the immediate business need if the user granted wide scopes or if the app keeps working after the original use case has changed. That creates governance friction because the security team must track both the user’s access and the app’s delegated reach.

GitHub Apps reduce that friction by making permissions more explicit and easier to audit at the repository level. They are designed for machine-to-machine style integration patterns where the application, not a human session, is the unit of access. That is why GitHub Apps usually produce better containment when a token, installation or integration is abused.

When you want to see the control problem from an authorisation perspective, the distinction maps cleanly to authorisation models: OAuth apps tend to inherit broader delegated authority, while GitHub Apps are closer to policy-driven, narrow entitlements. The same pattern is reflected in IAM and IGA basics, where access reviews, ownership and entitlement scope matter more when access is not tied to a single bounded installation.

What security teams should look for in practice

If the integration needs repository access only, prefer the model that can be limited to specific repositories and specific API capabilities. If the integration needs to act in the context of a user’s broader SaaS permissions, OAuth may be unavoidable, but it should then be treated as a higher-governance control point with explicit review and revocation.

For the underlying protocol mechanics, the OAuth side of the comparison is governed by RFC 6749, which defines the authorization framework and token-based delegated access model. Good practice for OAuth deployments also depends on tighter token handling and replay resistance, which is why current guidance such as RFC 9700 matters when an integration can reach valuable repositories or secrets.

For GitHub-specific governance, the operational question is whether the app can be installed only where needed, whether repository selection is explicit, and whether the permission set is narrow enough to survive review without constant exceptions. If the answer is no, the app is probably being used as a convenience layer for access that should have a clearer control owner.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP API Security Top 10	API5 — Broken Function Level Authorization	Repository integrations need function-level permission boundaries.
Recommendation — Restrict app capabilities to the exact repository actions required.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	OAuth vs GitHub Apps is fundamentally a privilege-scope choice.
	IA-5 — Authenticator Management	Both models rely on token and secret lifecycle control.
Recommendation — Assign the narrowest repository access needed for the integration. Rotate and revoke app credentials and tokens promptly.
ISO/IEC 27001:2022	A.5.15 — Access control	The question is about governing access to repositories and integrations.
	A.8.5 — Secure authentication	OAuth and GitHub App access both depend on secure token-based authentication.
Recommendation — Define and enforce repository access rules for each integration type. Use strong authentication and token handling for repository integrations.

Practitioner Guidance

What to prioritise: Treat repository access as an entitlement-design problem, not just an integration choice. The better default is the model that lets you limit access to the smallest repository set and the smallest action surface.

What to verify: Confirm who can grant the integration, what revocation looks like, whether the token or installation can outlive the original need, and whether access reviews can actually detect overreach. If the answer depends on a person staying continuously authorised, governance is weaker than it looks.

Common mistake: Teams often choose OAuth because it is faster to connect, then discover they have created a delegated-access path that is harder to inventory and harder to unwind than an installation-based app.

Practitioner takeaway: If the integration is supposed to touch only specific repositories, prefer the model that makes those boundaries explicit at install time, because that is what turns “access” into something you can govern, review and revoke cleanly.