Add my own explanation
The reference below is solid. Next step: re-explain GitHub tokens in my own words up here (Feynman-style), then keep the reference underneath as backup.
Reference explanation
GitHub access tokens are credentials that authenticate a user to GitHub’s API or git operations, used in place of a password. GitHub disabled password authentication for git/API in 2021 — tokens are now mandatory.
Two main flavors:
1. Personal Access Tokens (PATs)
Generated manually by the user in GitHub settings.
- Classic PATs — broad scopes (
repo,workflow,admin:org, etc.). A scope grants access across all repos the user can see. Coarse-grained. - Fine-grained PATs — scoped per-repository with granular permissions (read/write/admin per resource type). Preferred for security; principle of least privilege.
Used for:
git clone/pushover HTTPS.- CLI tools like
gh. - CI/CD pipelines, scripts, third-party tools that need API access.
2. OAuth tokens
Issued automatically when a user authorizes a GitHub OAuth App or GitHub App (e.g., Vercel, a CI provider, Claude Code) via the OAuth flow. The user never sees or copies these tokens manually — the app receives and stores them.
See OAuth for the underlying flow.
Why tokens instead of passwords:
- Scoped — limit blast radius if leaked.
- Revocable individually — kill one token without changing the password or affecting other tokens.
- Expiring — can have explicit expiration dates.
- 2FA-compatible — passwords don’t work with 2FA for API/git operations; tokens do.
Security hygiene:
- Treat tokens like passwords — never commit them to a repo, never paste them into chats or screenshots.
- If leaked, revoke immediately at GitHub Settings → Developer settings → Tokens.
- GitHub’s secret scanning will often catch leaked tokens automatically and notify the user, but don’t rely on it.
Open questions
- When should I use a fine-grained PAT vs. a GitHub App for automation?
- How do GitHub Apps differ from OAuth Apps under the hood?
- What’s the right way to handle token rotation in CI?