Why GitHub’s Short‑Lived OAuth Tokens and Multiple Redirect URIs Matter for AI Coding Assistants and Dev Tools

What Happened

GitHub changed its OAuth platform behavior to make short‑lived access tokens the default for new OAuth apps and added support for multiple redirect (callback) URIs per app. Key points:

• OAuth apps can opt into expiring access tokens: short‑lived access tokens (8 hours) plus refresh tokens (refresh tokens valid up to 6 months). To receive refresh tokens, request the offline_access scope during authorization or set the app registration to always use short‑lived tokens. Short‑lived tokens are the default for new apps; existing apps can disable temporarily while updating SDKs [1].
• OAuth apps may register up to 10 redirect URIs via a new “Add redirect URI” control to handle multiple environments/domains [1].
• Both OAuth apps and GitHub Apps can enable per‑URI wildcard matching to cover subdomains or paths. Legacy behavior: apps with a single redirect URI had wildcard matching enabled; owners should review and disable wildcarding if unnecessary because it increases attack surface [1].
• These changes also apply to GitHub Enterprise Server 3.23 [1].

Why It Matters to Businesses

For companies building AI coding assistants, editor integrations and developer tools (GitHub, Cursor, Windsurf, Replit, Sourcegraph, JetBrains, VS Code, Continue.dev and similar), the changes affect authentication design, security posture, user experience and operations:

• Security improvement with operational tradeoffs: Short‑lived access tokens reduce long‑term token abuse if an access token is leaked, but they require reliable refresh flows and secure storage of longer‑lived refresh tokens (valid up to 6 months) [1].
• Multi‑environment support: Up to 10 redirect URIs simplifies supporting local development, staging, QA and production without ad‑hoc workarounds, improving release velocity and reducing risky wildcard usage [1].
• Editor/extension changes: Public client integrations (VS Code, JetBrains, browser extensions) that cannot securely hold a client secret must use PKCE and a backend refresh service or rely on GitHub’s refresh tokens; this increases implementation complexity for AI assistants that run as editor extensions.
• Operational load: Shorter access token lifetimes increase token refresh frequency, adding API calls and complexity in token lifecycle management and monitoring.

Kimbodo Engineering Perspective

We treat these platform changes as net positive for risk reduction, but only if teams make targeted engineering investments. Key judgments and trade‑offs:

Trade‑offs

• Security vs. complexity: enforcing short‑lived tokens reduces window of token misuse but forces robust refresh, storage and rotation logic for refresh tokens. That is a one‑time engineering cost for ongoing security gains.
• Backend vs. client complexity: keeping refresh logic on a backend service centralizes secrets and reduces client attack surface, but introduces an operational component ( availability, scaling, secrets management ). For AI assistants embedded in editors, a small backend service is preferable to storing refresh tokens in extension state.
• Wildcard convenience vs. safety: enabling per‑URI wildcards can simplify routing but is a high‑risk convenience—only acceptable when redirect routes are tightly controlled and tested.

Practical rules of thumb

• Default to short‑lived access tokens with refresh token rotation and server‑side token storage for production integrations.
• Use exact redirect URI matching for public surfaces. Only use wildcards where you have a documented, tested need and compensate with extra validation.
• Limit registered redirect URIs to environments you control (use the 10 slots for dev, staging, prod, internal preview, feature test domains) and automate management via infrastructure as code.

How We Would Implement It

Concrete architecture choices and implementation steps for AI coding assistants and developer tools integrating with GitHub:

Architecture summary

• Centralized Auth Service (recommended): a small, highly available backend service that handles OAuth flows, stores refresh tokens in an encrypted secret store, exchanges for short‑lived access tokens, and issues ephemeral session tokens to clients.
• Client integrations (editor extensions, web UI): use PKCE for public clients, redirect to the centralized Auth Service, and receive short‑lived session tokens for API calls. Clients never persist refresh tokens.
• Token store and secrets manager: use a managed secrets store (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) or encrypted DB with access controls and audit logging for refresh tokens and client secrets.
• Observability and automation: track token refresh rates, failures, and revocations; alert on abnormal refresh patterns; automate rotation of client secrets and cleanup of unused redirect URIs.

Step‑by‑step implementation

• Register your OAuth app in GitHub; add up to 10 redirect URIs for each environment you control. Avoid wildcards unless required; if enabled, lock down routes and test thoroughly [1].
• Decide token model: enable short‑lived tokens and request offline_access to get refresh tokens, or use temporary disabling during SDK updates as needed [1].
• Implement PKCE for public clients (editor extensions) and require a backend relay for refresh token exchange for production deployments.
• Implement refresh token rotation: store refresh tokens encrypted, rotate on use, and revoke previous refresh tokens where supported. Schedule refresh ahead of the 8‑hour expiry window and retry with exponential backoff on failures.
• Add robust error handling: on refresh failure, force re‑auth in client; index metrics for failed refresh rates to detect token theft or platform issues.
• Automate management: maintain redirect URI lists in IaC so deployments add/remove URIs consistently; include tests for redirect handling during CI to avoid wildcard surprises.
• Audit and compliance: log token issuance and refresh operations, integrate with SIEM, and provide admins tools to revoke tokens and rotate client secrets quickly.

Risks, Costs and Security

Implementing the new model reduces long‑term risk but introduces operational and security considerations:

• Refresh token theft risk: refresh tokens are longer lived (up to 6 months). Storing them insecurely in client environments (extensions, local apps) significantly raises compromise risk. Mitigation: keep refresh tokens on a secure backend, encrypt at rest, and rotate on use.
• Increased operational cost: more frequent refreshes increase calls to GitHub’s token endpoints and require monitoring. Budget for additional API usage, infrastructure for the auth service, and engineering time to implement rotation and error handling.
• Complexity for public clients: Editor integrations and browser extensions require PKCE and a backend component for secure refresh handling—this increases deployment complexity and maintenance surface.
• Wildcard redirect misuse: enabling wildcard redirect matching without tight route controls can allow attackers to craft callback URIs that capture tokens. Best practice: use exact URI matching and only enable per‑URI wildcards after threat modeling and tests [1].
• Migration and backward compatibility: existing apps may need SDK and code changes to handle expiring tokens; GitHub allows temporarily disabling short‑lived tokens for upgrades, but plan migrations and test thoroughly [1].

Summary: adopt short‑lived access tokens as a security baseline, run refresh logic on a hardened backend, limit wildcard usage and register only required redirect URIs. These steps materially reduce authentication risk for AI coding assistants and developer tools while keeping operational costs and complexity predictable.

Sources

1. [1] Multiple redirect URIs and token refresh for OAuth apps