Deploy keys vs personal access tokens vs OAuth apps

When a third-party service needs to read your repository, you usually choose between a deploy key, a personal access token, or an OAuth app. They are not interchangeable. They differ in what they can reach, whose identity they act as, and how much damage a leak causes.

The right comparison is not "which is most convenient" but "what does an attacker get if this credential escapes".

What is a deploy key?

A deploy key is an SSH key pair bound to a single repository. You add the public key to that repository's settings; the holder of the private key can access that repository and nothing else.

Its defining property is a narrow scope by construction. A deploy key cannot enumerate your other repositories, cannot touch your account settings, and cannot act anywhere else — not because permissions say so, but because the credential is attached to one repository.

Deploy keys are typically configurable as read-only, which matters: a read-only deploy key cannot push, cannot force-push, cannot delete a branch, and cannot create a release.

The trade-off is administrative. One key per repository per service means more keys to manage. That is also the benefit — rotating one key affects exactly one connection.

What is a personal access token?

A personal access token authenticates as you. Depending on the platform and the token type, it may reach every repository your account can reach, including private ones and organisation repositories.

Classic tokens are especially broad: scopes are coarse, and a token with repository access typically reaches all your repositories rather than a chosen one. Newer fine-grained tokens are much better, allowing per-repository selection and granular permissions, and if you must use a token you should use that kind.

Two problems remain even then. First, the token carries your identity, so its actions appear as yours in the history and it inherits your access as that access changes. Second, it is tied to a person: when they leave, change roles, or rotate credentials, integrations break in ways nobody documented.

A leaked broad token is close to a worst case. It reads every repository the account can reach, and if it has write scope it can push code that later gets deployed.

What is an OAuth app or GitHub App?

An OAuth app or GitHub App acts as an application that a user or organisation grants access to. Access is delegated rather than shared: no long-lived secret of yours is handed over, permissions are declared, and an administrator can review and revoke the grant centrally.

A GitHub App is generally the strongest of the three for a service that needs ongoing access at scale. It can be installed on selected repositories, uses short-lived tokens derived from an installation, has its own identity in the audit history, and does not break when a person leaves.

The cost is complexity. Building and operating one is real work for the service provider, and the installation flow is heavier for the customer. For a service that needs read access to one repository, that machinery can be more than the situation calls for.

How do they compare on the questions that matter?

Blast radius if leaked. Deploy key: one repository, read-only if configured that way. Fine-grained token: the selected repositories with the selected permissions. Classic token: potentially everything the account can reach. App installation: the granted repositories, with short-lived credentials that expire.

Whose identity acts. Deploy key: the repository connection itself. Token: a specific human. App: the application.

Revocation. Deploy key: remove one public key from one repository, affecting nothing else. Token: revoking it breaks every integration that used it, often several. App: revoke the installation centrally.

Survives staff change. Deploy key: yes. Token: no. App: yes.

Write capability. Deploy key: optional, and should be off. Token: whatever the scope allows. App: whatever was granted.

Which should you choose?

Choose by what the service actually needs.

If it needs to read one repository, a read-only deploy key is the tightest fit and the easiest to reason about. There is no path from that credential to your other repositories, no dependency on an individual's account, and revocation is a single, obvious action.

If it needs write access or multiple repositories on an ongoing basis, an app installation is the appropriate mechanism.

A personal access token is the weakest option of the three for a machine integration, and a classic broad-scope token is worth avoiding entirely. It exists mainly because it is the fastest thing to paste into a form — which is exactly why it ends up in configuration files and shell history.

One rule holds regardless: if a service asks for write access to read your code, ask why. A service that only reads should only be able to read.

What does IssueProbe use?

IssueProbe generates one SSH deploy key for each connected website and requires read-only repository access. The service creates the key pair; only the public key is ever exposed, and the private key never appears in the dashboard or the API.

The setup accepts an SSH repository location, a default branch, and an optional full-length deployed revision. It does not accept a password, a personal token, a general SSH key, or an embedded credential — those are not valid inputs. A repository check confirms read access to the registered branch without any write operation, and verifies the exact repository host key before a clone.

Because each website has its own key, rotating one affects one repository. An owner can also correct the repository location, branch, host fingerprint, or pinned revision later; that clears the previous verification until a fresh check succeeds, but the deploy key stays the same, so no new public key needs adding.

Read why read-only deploy keys reduce repository risk for the reasoning in more depth, pinning the deployed commit for mapping a report to exact source, and the security page for the public controls.