Account Security, Two-Factor Authentication, SSH Keys, Tokens, and Credential Hygiene: Configuration, Design Choices, and Tradeoffs

1. Design principle: minimize reusable authority

Credential design is a blast-radius problem. A credential has a principal, a set of reachable resources, permitted operations, a lifetime, and a storage location. The safest useful design minimizes all five without making the system impossible to operate.

For interactive developer access, the credential should be tied to a specific device or managed credential store. For automation, the stronger pattern is a dedicated machine identity with short-lived credentials—such as a GitHub App installation token—rather than a long-lived PAT copied from a powerful engineer’s account.

2. SSH versus HTTPS for Git transport

Neither transport is “more authorized.” Both ultimately reach the same GitHub repository service and then face repository/ref policy. Choose the transport that fits your organization’s endpoint management, network controls, credential recovery, and developer experience.

3. HTTPS storage: delegate secret handling to a credential manager

GitHub recommends GitHub CLI or Git Credential Manager for HTTPS credentials. On supported platforms, GCM integrates with the operating system’s secure credential store and browser authentication. This is preferable to teaching each developer to generate a PAT and paste it whenever Git prompts.

If gh auth login cannot find a system credential store, current CLI documentation says it can fall back to a plain-text file. That does not automatically make the setup unusable, but it changes the threat model: file permissions, disk protection, shared-user machines, backups, and malware exposure become more important. Production workstation standards should define the expected credential backend.

4. Fine-grained PAT versus classic PAT

Fine-grained PATs are the default design candidate because you can narrow the resource owner, repositories, and permissions. However, GitHub’s current documentation lists scenarios that still require classic PAT behavior. These gaps are product policy and can change, so endpoint documentation—not a memorized 2026 list—must decide.

5. GitHub App installation tokens for automation

A GitHub App has its own registered permissions. An installation grants that App access to selected accounts/repositories, and an installation access token represents the installed App for a short period. Current GitHub documentation states installation access tokens expire after one hour.

This design is operationally useful because the automation identity is not a human, the repository set is explicit, permissions are configured centrally, tokens are short-lived, and app activity is attributable. The App’s private key remains a high-value credential used to mint installation tokens and therefore requires its own secret-storage/rotation controls.

6. GITHUB_TOKEN: prefer the built-in workflow identity when it is enough

For GitHub Actions, GitHub automatically creates a GITHUB_TOKEN for each job. It is an installation access token for the GitHub App installed for Actions and is limited to the workflow repository. Workflow permissions, repository/org defaults, and event context determine what it can do.

If a workflow only needs to read code, create a release, comment on an issue, or perform another supported operation in its own repository, start by asking whether GITHUB_TOKEN can satisfy the requirement. A personal PAT should not be the default simply because “the workflow needs an API token.”

7. Expiration: security control plus availability dependency

Shorter lifetime reduces the window in which a stolen bearer credential remains useful. But expiration without ownership and rotation creates outages. A production credential record should therefore include owner, purpose, resource scope, expiry, consumer locations, rotation lead time, and a test that proves the replacement works before the old credential is revoked.

8. Storage choices: “not in Git” is only the beginning

A credential copied out of source control can still leak through shell history, CI logs, process arguments, screenshots, crash dumps, clipboard history, backup systems, or overly broad environment inspection. The storage control must match how the credential is used.

9. SSO and organization policy change the authorization equation

Enterprise Cloud SAML SSO can require a PAT or user SSH key to be authorized for an organization after the user establishes a linked external identity. Fine-grained PAT selection can also be subject to organization approval and policy. Therefore a credential design document must name both the GitHub credential and the organization/enterprise authorization context.

Do not interpret an SSO denial as “use a more powerful token.” The correct fix is usually to establish/refresh the required SSO session or authorize the credential according to organization policy. If policy blocks PATs entirely, the correct architecture may be a GitHub App or another approved integration identity.

10. Decision table: choose the smallest durable credential

11. Worked scenario: Atlas release metadata bot

Atlas needs a bot that reads tags from ten repositories and opens release-tracking issues. A team member proposes a classic PAT from their personal account with broad repository scope and no expiration. It works, but it couples production automation to that person’s employment, permissions, token rotation, 2FA/account recovery, and offboarding.

A stronger target architecture is a GitHub App installed on only the ten repositories, with only the repository permissions required to read metadata and create issues. The service stores the App private key in an approved secret manager, mints installation tokens on demand, and logs installation/repository IDs—not token values. If the integration runs entirely inside one repository’s Actions workflow and needs only that repository, GITHUB_TOKEN may be even simpler.

12. Free-compatible design lab

Create a small credential design worksheet for these four actors: learner-laptop, local-read-script, repo-workflow, and atlas-integration. For each actor, record principal, credential type, resource scope, operations, lifetime, storage, revocation owner, and verification method.

No paid feature or live token is required. For atlas-integration, use a design-only GitHub App row. For the local script, compare “reuse managed gh authentication” against “temporary fine-grained PAT” and state why you would create the PAT only when the gh credential cannot meet the requirement.

13. Verification checklist

• Your transport choice separates network/credential-management concerns from repository authorization.
• Any PAT design names its resource owner, repositories, permissions/scopes, expiration, storage, and revocation owner.
• Classic PAT use has a documented compatibility reason rather than convenience.
• Automation designs prefer GITHUB_TOKEN or GitHub App installation tokens when those identities fit.
• Credential storage plans address shell history/logs/URLs—not only source control.
• Enterprise SSO is labeled as deployment/policy-specific and never treated as a universal GitHub rule.

Knowledge check

14. Summary

Credential selection is architecture. SSH and HTTPS solve Git transport with different device/network/storage tradeoffs. Fine-grained PATs are the preferred user-token candidate when supported; classic PATs are compatibility exceptions; GitHub Apps provide dedicated automation identity; GITHUB_TOKEN is the first choice for many repository-local Actions operations.

Least privilege includes resource scope, operation, lifetime, storage, revocation, and organizational policy. A credential is not “secure” because it has a strong algorithm; it is secure when its complete lifecycle and blast radius are controlled.

Authoritative references

• Caching GitHub credentials in Git
• Managing personal access tokens
• Permissions required for fine-grained PATs
• Authenticating with a GitHub App
• Choosing permissions for a GitHub App
• GITHUB_TOKEN
• About authentication with single sign-on
• Authorizing a PAT for SSO
• Authorizing an SSH key for SSO
• gh auth login
• GitHub CLI environment variables