What's changed: New GH-100 Chapter 3 (policies & rulesets = govern member capabilities vs enforce on code changes, enterprise cascade, audit log/SIEM streaming, defense in depth; repo security features = enable vulnerability alerts/secret scanning/CodeQL, default config, Dependabot/advisories, response plan/SECURITY.md; API & integrations = fine-grained PAT/least privilege/revocation, GitHub App vs OAuth App, rate limits, app approval/denial)
3.3Managing API Access and Integrations
Understand configuring personal access tokens (PATs), rate limits for PATs and GitHub Apps, the difference between GitHub Apps and OAuth Apps, and approving/denying apps based on policy.
GitHub is widely automated/integrated via APIs and apps. Admins govern who can use APIs/apps and with what authorization. GH-100 tests PATs, GitHub Apps / OAuth Apps, rate limits, and app approval/denial. The focus is "least-privilege authorization" and "governance via org policy."
3.3.1Personal access tokens (PATs)
A PAT is an API token a user issues. Classic PATs tend to be broadly scoped, so prefer fine-grained PATs with the target repos and permissions minimized and an expiration set. Orgs can use PAT policies to require approval for fine-grained PAT access or restrict classic PATs. Treat PATs like secrets and revoke them on leakage.
3.3.2GitHub Apps vs OAuth Apps
Integrations come as GitHub Apps and OAuth Apps. A GitHub App has its own identity, grants fine-grained permissions scoped to the installed repos/org, and runs on short-lived tokens—least-privilege and secure (recommended). An OAuth App acts on behalf of the user’s permissions and can reach everything the user can, tending to be coarse-grained. Orgs control which apps are allowed via an OAuth App access policy. Prefer GitHub Apps for new integrations and gate with approval as needed.
3.3.3Rate limits and approving/denying apps
APIs have rate limits capping requests per time window. GitHub Apps (installation tokens) often have higher rate limits than PATs, suiting larger automation—when heavy API usage hits PAT limits, migrating to a GitHub App is the norm. App adoption is controlled by org policy approval/denial—admins review and approve apps members request and deny unneeded/suspicious ones, curbing supply-chain-style app-borne risk.
Common: (1) PATs: fine-grained + least privilege + expiration; revoke on leak; org policy gates/restricts. (2) GitHub App = own identity, fine-grained, install-scoped, short-lived tokens (recommended); OAuth App = acts on the user’s permissions (coarse). (3) GitHub Apps have higher rate limits than PATs—suited to large automation. (4) Govern apps via org approval/denial to curb app-borne risk.
Watch out: (1) Classic PATs tend to be broad—use fine-grained PATs at least privilege. (2) Don’t confuse GitHub Apps (own identity, least privilege) with OAuth Apps (borrow user permissions)—prefer GitHub Apps for new integrations. (3) For large automation hitting rate limits, use a GitHub App over a PAT. (4) Approving apps without review lets over-permissioned apps become risk—govern with approval.
3.3.4Section summary
- PATs: fine-grained + least privilege + expiration; revoke on leak; org policy gates/restricts
- GitHub App = own identity/fine-grained/install-scoped/short-lived (recommended); OAuth App = borrows user permissions (coarse)
- GitHub Apps have higher rate limits than PATs—suited to large automation
- Govern apps via org approval/denial to curb app-borne risk
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which recommended personal API token type scopes target repos/permissions minimally and sets an expiration?
Q2. For new integrations, which recommended app type has its own identity, fine-grained install-scoped permissions, and short-lived tokens?
Q3. Which correctly describes an OAuth App’s permissions?
Q4. Automation making heavy API calls hits PAT rate limits. The standard response?
Q5. You want to govern third-party apps members request to install. Appropriate method?
Q6. Which is safe operation for a PAT?