Weekly DevOps Roundup - GitHub OAuth and Response Controls
This week's DevOps roundup focuses on practical hardening work in GitHub that reduces auth friction while improving incident response. OAuth apps now support refresh tokens and up to 10 callback URLs, making it easier to run clean dev/staging/prod setups without risky wildcard redirects. On the operations side, GitHub Enterprise adds token-type-specific credential revocation with audit logs and user notifications, so security teams can contain incidents without forcing disruptive, broad resets.
This Week's Overview
OAuth and incident response hardening in GitHub
Building on last week's push to make GitHub workflows more policy-driven and auditable (from PR rulesets to Code Quality behavior), GitHub is tightening some of the most failure-prone edges in auth and incident response so teams can scale automation without creating hard-to-debug security and compliance gaps.
GitHub OAuth apps can now use refresh tokens and multiple callback URLs, which removes two common production pain points: short-lived access tokens and environment-specific redirect URI sprawl. Access tokens are now 8 hours, backed by 6-month refresh tokens, and you enable the flow with the offline_access scope.
Support for up to 10 callback URLs helps teams keep clean separation across dev/staging/prod without resorting to fragile wildcard redirect patterns. GitHub explicitly calls out legacy wildcard redirect URI matching as something to audit, since overly broad redirect rules are a common OAuth footgun.
On the incident response side, GitHub Enterprise adds credential revocation and deauthorization by token type (PATs, SSH keys, OAuth tokens, and GitHub App user tokens), with audit logging and user notifications. For security teams, that means you can respond surgically (invalidate only the affected token class) rather than forcing broad, disruptive credential resets.