# GitHub’s OAuth apps get short-lived tokens, multiple callbacks — and a wildcard setting worth auditing GitHub has modernized its older OAuth app flow with rotating credentials and multiple callback URLs, while exposing a legacy wildcard behavior that existing app owners should review before it turns into a redirect-security problem. GitHub OAuth apps can now use eight-hour access tokens with rotating refresh tokens, register up to 10 callback URLs, and explicitly control wildcard callback matching. New apps default to expiring tokens, while existing single-callback apps should review a legacy wildcard setting GitHub has now made visible. - Status: Active - Published: 2026-08-16T10:36:30+12:00 - Updated: 2026-08-16T10:36:30+12:00 - Categories: Web Development, Developer Tools - Tags: Authentication, Developer tools, GitHub, OAuth, OAuth apps, Redirect URIs, Refresh tokens, security - Canonical HTML: https://beyondthe.news/dossiers/github-oauth-short-lived-tokens-multiple-callbacks-wildcard-audit ## What changed 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. ## Why it matters 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. ## OAuth apps can now rotate credentials instead of relying on long-lived bearer tokens 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. ## Multiple callbacks remove the need for one OAuth registration per environment 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. ## The wildcard control is the part existing app owners should audit 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. ## The safest migration is incremental, not a flag flip 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 Enterprise Server follows in 3.23 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. ## Key details - OAuth app access tokens can now expire after eight hours. - Refresh tokens are valid for six months; using one returns a new token pair and invalidates the previous access and refresh tokens. - Requesting the `offline_access` scope lets developers test the expiring-token flow before requiring it for all clients. - Short-lived tokens are enabled by default for newly created OAuth apps. - OAuth apps can register up to 10 callback URLs. - GitHub Apps and OAuth apps can explicitly control wildcard matching for callback URLs. - Existing apps with a single callback URL had wildcard matching as legacy behavior; GitHub has now made that setting visible and configurable. - GitHub Enterprise Server support is scheduled for version 3.23. ## Builder takeaways - Audit every GitHub OAuth app and GitHub App that has a single callback URL. If wildcard matching is enabled and the product does not require it, turn it off rather than relying on legacy behavior. - Add refresh-token support before forcing expiring access tokens. Use `offline_access` on selected sign-ins to test storage, refresh, retry, revocation, and re-authentication paths in production-like conditions. - Store the refreshed token pair atomically. GitHub invalidates the previous access token and refresh token when a refresh succeeds, so partial persistence can strand a session. - Replace wildcard callbacks with explicit production, staging, and regional callback URLs where the new 10-URL allowance is sufficient. This reduces redirect attack surface without needing separate OAuth registrations. - If you support GitHub Enterprise Server as well as GitHub.com, handle both token shapes: older Enterprise Server versions may ignore `offline_access` and return a non-expiring access token with no refresh token. ## What to watch - Adoption of refresh-token support in popular GitHub OAuth SDKs and frameworks, since GitHub allows apps to disable the new default while clients catch up. - The GitHub Enterprise Server 3.23 release and how quickly self-hosted customers gain parity with GitHub.com for expiring OAuth tokens and callback controls. - Whether GitHub later changes defaults or migration policy for existing OAuth apps; the August 14 announcement only makes short-lived tokens the default for new registrations. ## Uncertainties - GitHub has not announced a forced migration date for existing OAuth apps that still use non-expiring access tokens. - Products supporting older GitHub Enterprise Server versions cannot assume `offline_access` produces a refresh token; GitHub documents that unsupported servers may return the legacy non-expiring token instead. ## Timeline - **2026-08-14 — GitHub ships OAuth app token rotation and callback changes:** GitHub announces expiring access tokens and refresh tokens for OAuth apps, up to 10 callback URLs, explicit wildcard matching controls, and notes that single-callback apps inherited wildcard behavior under the legacy model. ## Sources - [Multiple redirect URIs and token refresh for OAuth apps](https://github.blog/changelog/2026-08-14-multiple-redirect-uris-and-token-refresh-for-oauth-apps/) — GitHub · official_changelog · 2026-08-14T00:00:00+12:00. Primary announcement for expiring access tokens, refresh tokens, multiple callback URLs, wildcard controls, legacy single-callback wildcard behavior, and GHES 3.23 support. - [Authorizing OAuth apps](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps) — GitHub Docs · official_documentation. Primary implementation documentation for `offline_access`, eight-hour access-token expiry, six-month refresh-token expiry, token rotation behavior, and GitHub Enterprise Server compatibility. - [Best practices for creating a GitHub App](https://docs.github.com/en/apps/creating-github-apps/about-creating-github-apps/best-practices-for-creating-a-github-app) — GitHub Docs · official_documentation. GitHub security guidance warning that wildcard callback matching can expose authorization codes to attacker-controlled subdomains or subdirectories. - [RFC 9700: Best Current Practice for OAuth 2.0 Security](https://www.rfc-editor.org/info/rfc9700/) — RFC Editor / IETF · standard · 2025-01-30T00:00:00+13:00. OAuth 2.0 security best current practice explaining redirect-URI validation risks, including wildcard patterns and subdomain takeover scenarios.