GitHub’s OAuth apps get short-lived tokens, multiple callbacks — and a wildcard setting worth auditing

On August 14, 2026, GitHub added three linked OAuth-platform changes: OAuth apps can opt into short-lived access tokens with refresh-token rotation, register up to 10 callback URLs, and explicitly enable or disable wildcard matching on callback URLs. Short-lived tokens are enabled by default for newly created OAuth apps. GitHub also surfaced a legacy behavior: apps with only one registered callback URL already had wildcard matching enabled, so existing app owners can now see and turn off that behavior when it is unnecessary.

For SaaS products and developer tools that use GitHub sign-in or GitHub API access, this removes two long-standing implementation compromises while creating a concrete security-review task. Teams no longer need separate OAuth registrations just to support multiple environments or domains, and they can reduce the blast radius of a stolen bearer token by moving from effectively long-lived credentials to eight-hour access tokens. The catch is redirect handling: GitHub warns that wildcard matching can send authorization codes to attacker-controlled subdomains or paths if an application does not fully control them, and current OAuth security best practice treats broad redirect matching as a meaningful attack surface.

GitHub OAuth apps can request an access token that expires after eight hours together with a refresh token valid for six months. Developers can introduce the flow gradually by requesting the `offline_access` scope during authorization, or configure the OAuth app so all clients receive short-lived tokens. Refreshing returns a new access-token/refresh-token pair and invalidates the old pair. GitHub says short-lived tokens are enabled by default for new OAuth app registrations; apps whose SDKs do not yet support refresh can temporarily disable the setting while they migrate.

OAuth apps can now register up to 10 callback URLs. That is directly useful for products that previously created separate GitHub OAuth apps for production, staging, regional domains, or other deployment configurations simply because one registration accepted only one callback. The new model lets those environments live under one app registration without depending on broad URL matching.

GitHub Apps and OAuth apps can now explicitly enable wildcard matching for individual callback URLs. GitHub warns that the setting should be used only when the application controls every subdomain and path that could match, because an authorization code can otherwise be redirected to an attacker-controlled location. More importantly for existing installations, GitHub says apps with only one callback URL already had wildcard matching as legacy behavior; the change makes that behavior visible and controllable. That turns this release into more than a convenience upgrade: app owners have a concrete configuration to review even if they do not plan to adopt multiple callbacks or expiring tokens yet.

Builders can first add refresh-token handling and exercise it by requesting `offline_access` for selected authorization flows before making expiring tokens mandatory for every client. Code should not assume a refresh token is always returned if the product also supports older GitHub Enterprise Server instances; GitHub documents that an Enterprise Server version without expiring-token support may ignore `offline_access` and return a non-expiring token. Callback URLs should be made explicit wherever possible, with wildcard matching disabled unless the tenancy model genuinely requires it.

GitHub says the OAuth and callback improvements will be included in GitHub Enterprise Server 3.23. That matters for products supporting both GitHub.com and self-hosted GitHub: capability detection and backward-compatible token handling remain necessary until supported Enterprise Server versions are broadly deployed.