Introduction

If your goal is "read one private repository and nothing else," the first thing to clarify is which GitHub credential type you are using. A classic OAuth app token is scoped broadly and is not the best tool for single-repository restriction. In current GitHub workflows, the two practical choices are a fine-grained personal access token for a human user or a GitHub App installed on just the target repository.

Why a Plain OAuth App Token Is the Wrong Fit

Traditional GitHub OAuth app tokens are authorized through scopes such as repo. Those scopes are coarse. They describe categories of access, not one specific repository.

That means an OAuth token from a standard OAuth app can often answer the question "can this app read private repos for this user," but not the question "can this app read exactly one private repo and nothing else."

If you need per-repository restriction, do not try to fake it in application code by checking the repository name after the token is issued. That still leaves the token overpowered.

Option 1: Fine-Grained Personal Access Token

For user-driven automation, a fine-grained personal access token is the simplest current option. When creating the token, GitHub lets you choose specific repositories and repository-level permissions.

A typical setup is:

• select only the one private repository
• grant read-only contents permission
• avoid broader account permissions unless required

Once created, use it like any other HTTPS token.

git clone https://USERNAME:[email protected]/OWNER/private-repo.git

Or call the API with it:

1curl \
2  -H "Authorization: Bearer TOKEN" \
3  -H "Accept: application/vnd.github+json" \
4  https://api.github.com/repos/OWNER/private-repo

This is a good fit when the access is acting on behalf of a user and you want the narrowest practical repository scope.

Option 2: GitHub App

If the integration is for a service, bot, or production system, a GitHub App is usually the better design. GitHub Apps install into selected repositories, and their permissions are defined explicitly.

That makes them naturally aligned with the requirement "one app, one private repo, read only."

A GitHub App flow looks like this at a high level:

1. create the app with only the repository permissions you need
2. install it on the target repository only
3. generate an installation access token
4. use that token for API access

For example, after generating an installation token in your backend, you can call the repository API:

1curl \
2  -H "Authorization: Bearer INSTALLATION_TOKEN" \
3  -H "Accept: application/vnd.github+json" \
4  https://api.github.com/repos/OWNER/private-repo/contents/README.md

Compared with OAuth app tokens, GitHub Apps are easier to audit and safer for long-lived integrations.

Which Option Should You Choose

Use a fine-grained personal access token when:

• a human user needs temporary or simple scripted access
• you want quick setup with minimal moving parts

Use a GitHub App when:

• the integration belongs to a service, bot, or backend system
• you need repository-specific installation control
• you want better long-term permission management

If someone asks specifically about an OAuth2 token, the important answer is that classic OAuth app tokens are not the ideal mechanism for this exact security requirement.

Common Pitfalls

• Using a classic OAuth app token with broad repo access and trying to enforce repository limits only in app logic.
• Confusing classic personal access tokens with fine-grained personal access tokens.
• Choosing a user token for a production integration that should really be a GitHub App.
• Granting write permissions when read-only contents access is enough.
• Forgetting to review which repositories were selected when the token or app was created.

Summary

• Classic GitHub OAuth app tokens are too coarse for strict single-private-repo access.
• For user-driven access, use a fine-grained personal access token limited to the target repository.
• For service integrations, prefer a GitHub App installed only on that repository.
• Give only the minimum repository permission, usually read-only contents.
• Do not rely on application-side checks to compensate for an over-scoped token.