GitHub authorization is the act of granting an application permission to act on your account or your repositories, and it happens through one of four mechanisms: OAuth Apps and GitHub Apps (authorize, then usually install), personal access tokens (classic or fine-grained), and SSH or deploy keys. Each grants a different scope: an OAuth App typically gets broad account-level access, a GitHub App gets repository-level permissions approved per installation, a fine-grained PAT gets exactly the scopes and repos selected, and a deploy key gets read or write access to one repository only.
Authorize and install are two different actions that GitHub’s own UI does not always separate clearly, and the difference matters because they grant different things. This is a map of the mechanisms, what a deploy platform typically uses and why, and how to check and revoke what you have already granted.
Table of contents
- Authorize vs Install: The Distinction That Trips People Up
- OAuth Apps vs GitHub Apps
- Personal Access Tokens: Classic vs Fine-Grained
- SSH Keys and Deploy Keys
- Which Mechanism a Deploy Platform Actually Uses, and Why
- Least Privilege: What to Actually Grant
- Auditing What You Have Authorized
- Revoking Access
- How this fits the rest of the stack
- FAQ
Authorize vs Install: The Distinction That Trips People Up
Authorizing an application means you are letting it identify as you and act with some set of permissions tied to your GitHub account. Installing a GitHub App is a separate step that grants it access to specific repositories, independent of your personal account permissions. An OAuth App is authorized once and that is the whole grant; a GitHub App is typically authorized, so it knows who you are, and then installed, so it knows which repos it can touch.
The practical effect: revoking authorization for a GitHub App does not necessarily remove its installation on your repositories, and removing the installation does not necessarily revoke the authorization. Both need checking separately.
OAuth Apps vs GitHub Apps
OAuth Apps are the older mechanism. They authenticate as the user who authorized them, request broad scopes such as repo, which means every repository you can access, and have no concept of a per-repository install.
GitHub Apps authenticate as themselves, not as a user, request permissions at a finer grain, read-only contents, pull requests, checks, and so on individually, and are installed on a chosen subset of repositories rather than granted account-wide access. Most deploy platforms and CI tools built after GitHub Apps existed use this mechanism specifically because it avoids handing over account-wide scope for a job that only needs to read one repository.
Personal Access Tokens: Classic vs Fine-Grained
A classic PAT is a single token with broad, account-wide scopes picked once, repo, workflow, admin:org, valid until you revoke it or it expires. A fine-grained PAT scopes to specific repositories and specific permissions within them, contents read but not admin, with a mandatory expiration date.
Fine-grained tokens are the better default for anything you are setting up yourself, a CI script, a local tool, because a leaked fine-grained token exposes one repository’s read access instead of every private repository you own. The trade-off is more setup: picking repositories and permissions explicitly instead of ticking a single repo checkbox, and re-creating the token when its expiration date arrives rather than a token that quietly lives forever.
SSH Keys and Deploy Keys
An SSH key added to your personal account authenticates you for every repository you can access over SSH, the same broad-scope problem as a classic PAT. A deploy key is added to a single repository, grants access to that repository only, and can be read-only or read-write. It is the narrowest mechanism on this list, and the right choice when only one repository needs access, such as a server that pulls one codebase.
The distinction matters most for automation that lives outside your own machine: a build server, a deployment script, or a scheduled job. Giving that job a personal SSH key means a compromised server can reach every repository you can, where a deploy key limits the blast radius to the one repository it was issued for.
Which Mechanism a Deploy Platform Actually Uses, and Why
A platform that builds and deploys from your repositories almost always uses a GitHub App rather than an OAuth App or a PAT, because it needs to act on repositories you choose to connect without holding account-wide scope, and because a GitHub App’s installation can be limited to selected repositories from the start. The permissions it typically requests are read access to contents and metadata, plus write access to commit statuses or checks so it can report build results back onto your commits and pull requests.
That is a meaningfully smaller grant than authorizing an OAuth App with the repo scope, which would hand over read and write access to every repository, public and private, that you can see.
Least Privilege: What to Actually Grant
Grant the narrowest thing that gets the job done: a GitHub App installed on the specific repositories it needs, not your whole account; a fine-grained PAT with an expiration and read-only scope where write is not required; a deploy key over an SSH key added to your personal account when only one repository is involved.
- Prefer GitHub App installations scoped to selected repositories over OAuth Apps
- Prefer fine-grained PATs with an expiration over classic PATs with none
- Prefer a repository deploy key over a personal SSH key for single-repo automation
- Review requested permissions before approving, not just the app’s name
Auditing What You Have Authorized
GitHub Settings has two separate pages worth checking periodically: Applications, which lists every OAuth App and GitHub App you have authorized along with the scopes or permissions granted, and, per organization, the installed GitHub Apps with the repositories each one can see. Personal access tokens live under Developer settings, listed with their scopes and, for fine-grained tokens, their expiration date.
Check the official GitHub guide to reviewing authorized integrations for the exact settings paths, since GitHub moves these periodically. A five-minute pass through both lists every few months catches grants from tools you tried once and never removed.
Revoking Access
Revoking an OAuth App’s authorization on the Applications page immediately invalidates any token it was using. Removing a GitHub App’s installation removes its access to those repositories, but does not delete the app’s separate authorization if you also signed in through it, check both. Deleting a personal access token or a deploy key takes effect immediately, and any process still using it starts failing on its next request.
There is no soft-revoke or grace period on any of these, which is the correct behaviour for a security control but worth knowing before revoking something a working deploy pipeline still depends on. Confirm nothing active uses the grant before removing it, not after.
How this fits the rest of the stack
A deploy platform that only needs to read your repository and post a build status back onto a commit should never be asking for the same access an OAuth App’s repo scope grants. A GitHub App scoped to the repositories you choose, with the install and the permissions visible on the GitHub connection page rather than buried in account settings, is the version of this worth signing up for. What a service and a database cost once that connection is made is on the RunxBuild hosting calculator.
Useful related references:
- GitHub API Requires Authentication: The Five Causes of the 401, in the Order to Check Them
- Password Authentication Is Not Supported for Git Operations: The Fix and the Reason
- Git vs GitHub vs GitLab: One Is a Program, Two Are Companies
- Deploying from GitHub on RunxBuild
FAQ
What does authorize GitHub App mean?
It means granting the app permission to identify as you and access whatever it requested, usually your profile information and, if it requests it, repository access. For GitHub Apps specifically, authorization confirms who you are; a separate installation step determines which repositories the app can actually touch.
What is the difference between a GitHub App and an OAuth App?
An OAuth App authenticates as the user who authorized it and typically requests broad, account-wide scopes such as repo. A GitHub App authenticates as itself, requests fine-grained permissions per capability, and is installed on a chosen subset of repositories rather than your whole account.
How do I revoke a GitHub authorization?
Go to Settings, then Applications, find the OAuth App or GitHub App, and revoke it, which invalidates any token it holds immediately. If it is a GitHub App you also installed on repositories, check the organization or account’s installed apps list separately, since removing the installation and revoking the authorization are different actions.
Is it safe to authorize a third-party GitHub app?
It depends entirely on the permissions requested, not the app’s name or popularity. A GitHub App asking for read-only access to a few named repositories is a small grant; an OAuth App requesting the repo scope is access to everything you can see, public and private, and deserves more scrutiny before approving.