OAuthアプリに複数リダイレクトURIとトークンリフレッシュ機能が追加Multiple redirect URIs and token refresh for OAuth apps

GitHub has rolled out a set of updates to its OAuth app and GitHub App platforms aimed at strengthening how third-party applications authenticate against its APIs. The headline changes let OAuth apps opt in to expiring access tokens paired with refresh tokens, and add support for registering multiple redirect URIs per application. For anyone building integrations on top of GitHub, these are practical improvements to the security posture of common authentication flows.

The most security-relevant addition is optional token expiration. Historically, access tokens issued through GitHub's OAuth app flow did not expire on their own, which meant that a token leaked through a log file, a misconfigured environment variable, or a compromised dependency could remain valid until it was manually revoked. By opting in to expiring access tokens, an app instead receives a short-lived access token alongside a refresh token. When the access token lapses, the application exchanges the refresh token for a new access token without requiring the user to re-authorize the app. This narrows the window during which a stolen credential is useful and aligns GitHub's OAuth apps with a widely recommended pattern in the OAuth 2.0 ecosystem.

The word "opt in" is important here. Because expiring tokens change how an application manages credentials, existing integrations are not forced to adopt the behavior immediately. Developers who enable it will need to implement refresh logic, handle expiry gracefully, and store refresh tokens securely, since a refresh token effectively becomes the long-lived secret in this model. Teams adopting the flow should plan for token rotation and revocation handling as part of the migration rather than treating it as a drop-in switch.

The second change addresses a long-standing friction point: support for multiple redirect URIs on a single app registration. The redirect URI is the callback endpoint GitHub sends users back to after they authorize an app, and it is validated to prevent authorization codes from being redirected to an attacker-controlled destination. Previously, teams often worked around the single-URI limitation by creating separate app registrations for development, staging, and production, or by routing all environments through one endpoint. Allowing multiple registered URIs lets a single app serve several environments or callback paths while still keeping the strict matching that makes redirect validation a security control. It reduces registration sprawl and the configuration drift that can accompany it.

These updates bring OAuth apps closer to the model GitHub already offers through GitHub Apps, and understanding the distinction is useful context. GitHub Apps are the newer, more granular integration type: they act on their own identity via installation tokens, support fine-grained repository and organization permissions, and already issue short-lived tokens by default. OAuth apps, by contrast, act on behalf of a user and have traditionally used broader scopes and non-expiring tokens. GitHub has generally steered developers toward GitHub Apps for new integrations, but OAuth apps remain widely used, so extending expiring-token and refresh support to them appears intended to raise the baseline security of that installed base without requiring a full migration.

The moves also fit a broader industry direction toward short-lived credentials and away from static, long-lived secrets. Refresh token flows, token rotation, and reduced credential lifetimes are increasingly standard guidance in identity and access management, echoed in OAuth 2.0 security best-practice documents and in the credential-handling patterns promoted across major cloud and developer platforms. GitHub has pursued related efforts elsewhere, including fine-grained personal access tokens, push protection and secret scanning to catch exposed credentials, and OpenID Connect support that lets CI/CD workflows obtain short-lived cloud credentials instead of storing static keys.

For developers, the immediate takeaway is that these are opt-in capabilities rather than breaking changes, so existing apps should continue to function while teams evaluate adoption. Those maintaining OAuth apps will likely want to review whether enabling expiring tokens is appropriate for their use case, confirm that their infrastructure can persist and rotate refresh tokens safely, and consolidate any duplicate registrations now that multiple redirect URIs are available. As with any authentication change, testing the refresh and callback flows across environments before enabling them in production is prudent, and consulting GitHub's official changelog and documentation is advisable for the precise configuration steps and any limitations.