[source-github] Add GitHub App Authentication to the GitHub Source Connector

[Lucas Leadbetter (lleadbet)]

Summary

The GitHub source currently supports two authentication methods: OAuth and Personal Access Tokens (PATs). Adding GitHub App authentication as a third option addresses some concerns around rate limits and alignment with GitHub's own recommended best practices.

Current State

Today, the GitHub source connector authenticates using:

1. OAuth: Issues a user-scoped access token with broad repo-level permissions. Tokens are long-lived and tied to an individual user account.
2. Personal Access Tokens: Classic PATs that also bind to an individual user account. The connector supports comma-separated multiple PATs to load-balance API quota, which is itself a workaround for the rate limit constraints of user-based auth.

Both methods share a fundamental limitation: they tie API access to a specific person. When that person leaves the organization, changes roles, or revokes their token, every Airbyte connection using that credential breaks.

Benefits of adding GitHub App Auth

Better Rate Limits

GitHub's rate limit tiers differ dramatically by auth method:

Auth Method	REST API Limit
Personal Access Token	5,000 req/hr per user
OAuth App token	5,000 req/hr per user (15,000 for GitHub Enterprise Cloud org members)
GitHub App (installation token)	5,000 base + 50 req/hr per repository + 50 req/hr per org user (up to 12,500 req/hr)

For organizations with hundreds of repositories, a GitHub App installation token can reach the 12,500 req/hr ceiling - more than double the standard PAT limit.

The GraphQL API limits scale similarly: GitHub Apps get a higher point budget, which benefits streams like pull_request_stats, reviews, releases, and projects_v2 that use GraphQL.

Decoupled from an Individual User

GitHub App authentication is org-level, not person-level. The App is installed on the organization, and access persists regardless of employee turnover.

With App auth, the credential lifecycle is managed by org admins, not individual contributors.

Fine-Grained, Least-Privilege Permissions

OAuth and classic PATs use coarse-grained scopes. The current connector requires the repo scope, which grants full read/write access to all repository content, settings, and webhooks.

GitHub Apps use targeted permissions (e.g., read-only access to repository contents, issues, pull requests, and metadata individually). This means:

• The connector only gets the access it actually needs
• Org admins have visibility into exactly what permissions are granted
• The blast radius of a leaked credential is significantly smaller

Short-Lived Tokens

GitHub App installation tokens expire after 1 hour and are regenerated automatically using a private key and JWT flow. Compare this to:

• Classic PATs: Never expire unless manually set or revoked
• OAuth tokens: Long-lived until explicitly revoked

Short-lived tokens reduce the window of exposure if credentials are compromised and align with zero-trust security practices that many organizations now require.

Alignment with GitHub's Recommended Direction

GitHub officially recommends GitHub Apps over OAuth Apps for all new integrations. From their documentation:

"In general, GitHub Apps are preferred over OAuth apps. GitHub Apps use fine-grained permissions, give the user more control over which repositories the app can access, and use short-lived tokens."

GitHub has been investing in fine-grained PATs as an incremental improvement, but GitHub Apps remain the gold standard for application-level integrations. Supporting App auth positions the Airbyte GitHub connector alongside first-class GitHub ecosystem tooling like GitHub Actions, Dependabot, and major CI/CD platforms - all of which use App auth.

Repository-Scoped Access

With a GitHub App, organization owners choose exactly which repositories the App can access at install time. This provides a clean boundary:

• Install the App on specific repos to sync only those repos
• Install on the entire org to sync everything
• Change the repo set at any time without touching Airbyte config

This is more intuitive and more secure than managing repo access through token scopes or user membership.

Who Benefits

• Enterprise customers who require least-privilege access, token rotation policies, and audit trails for all API integrations
• Large organizations hitting rate limits when syncing hundreds of repos - the scaling rate limit model directly solves this pain point
• Security-conscious teams that prohibit long-lived PATs or require all integrations to use short-lived, auto-rotating credentials
• Platform teams managing Airbyte connections at scale who need auth that survives employee offboarding without manual credential rotation

[airbyte-support-bot]

Hi Lucas Leadbetter (@lleadbet), thank you for this detailed and well-researched feature request!

Your analysis of the benefits of GitHub App authentication — including the improved rate limits, fine-grained permissions, short-lived tokens, and decoupling from individual user accounts — is thorough and compelling. These are all important considerations for organizations managing Airbyte connections at scale.

We have escalated this to our internal team for investigation. This feature request is being tracked internally: https://github.com/airbytehq/oncall/issues/11694

---

Need more help? Join Airbyte Community Slack for peer support, or if you're a Cloud customer, open a support ticket referencing this URL.