GitHub App vs OAuth: what's the difference and why it matters for automation

If you're building a tool that connects to GitHub on behalf of users, you have two options: OAuth Apps (personal access tokens) and GitHub Apps (installation-scoped tokens). They behave very differently, and the difference matters for security, reliability, and scale.

OAuth Apps: personal, broad, fragile

A GitHub OAuth App authenticates as the user. When you connect your GitHub account to a tool via OAuth, that tool gets a token that acts as you — with your permissions, your rate limits, and your scope of access.

This creates three problems at scale:

• Token churn. If the user revokes their GitHub access, rotates their token, or leaves the organisation, the integration breaks.
• Fan-out. If 100 users in the same organisation have connected the tool, an incoming webhook has to determine which of the 100 users it belongs to — an O(N) lookup.
• Over-permissioning. OAuth scopes are coarse. A tool that only needs to read CI results ends up with the same token permissions as the user's full GitHub access.

GitHub Apps: organisation-scoped, granular, revokable

A GitHub App is installed at the organisation or repository level. Instead of authenticating as a user, it authenticates as itself — with a private key that generates short-lived installation access tokens (1-hour TTL, auto-refreshed).

This solves all three OAuth problems:

• No token churn. The App's credentials are independent of any individual user's GitHub account.
• O(1) fan-out. An incoming webhook contains the installation ID. One DB lookup → one owner → process once.
• Granular permissions. The App requests only the scopes it actually needs — read-only checks, pull request metadata, issues write.

How Deviera handles both

Deviera supports both modes via a dual-mode token resolver in src/lib/github-app.ts. When an automation needs to make a GitHub API call:

1. Check for a GitHubAppInstallation record for the user. If found, generate an installation access token using the App's private key (JWT-signed, 5-minute refresh margin).
2. If no App installation exists, fall back to the user's OAuth access token from the Account table.

Callers get a token regardless of which path was taken. The dual-mode design means existing OAuth users keep working while new users who install the App get the better security model.

What this means for security

For teams evaluating Deviera for Enterprise use, GitHub App authentication is the more secure path:

• Tokens are short-lived (1 hour) and auto-rotated — no long-lived credentials to leak.
• The App can be revoked centrally from GitHub without touching any individual user account.
• The permission set is auditable in GitHub's App settings — exactly what was granted and when.

We recommend installing the Deviera GitHub App rather than relying on OAuth for all new workspaces. The install takes 30 seconds and the security benefits are immediate.