GitHub OAuth Redirect URIs and Refresh Tokens: A Security Guide

TL;DR

GitHub's August 2026 update for OAuth apps adds two changes that matter to anyone shipping developer tools, desktop utilities, mobile companions, or internal automation: OAuth apps can now register multiple redirect URIs, and app owners can opt in to expiring user tokens with refresh tokens. The feature looks small in a changelog, but it changes how teams should design authentication flows across staging, production, CLI callbacks, localhost testing, and mobile deep links. If you build or evaluate software, treat this as a prompt to audit every OAuth integration, confirm the redirect list is intentional, and document which tools in your stack really need persistent account access. For readers comparing utilities, the BTTC software catalog is a useful place to think about download trust, update behavior, and account-permission hygiene.

Why GitHub's OAuth update is timely

OAuth is one of the most common places where a useful tool becomes a security liability. A product may start with one production callback URL, then accumulate a staging domain, a preview deployment, a documentation demo, a localhost callback for development, and a custom scheme for a desktop or mobile app. Before this update, many teams worked around that reality by creating extra apps or by broadening a single redirect pattern. Both approaches create operational confusion. Multiple app registrations fragment analytics, permissions, and ownership. Overly broad redirect rules make it easier for a mistake in one environment to become an account takeover path.

GitHub says OAuth apps can now have up to ten redirect URIs, and each redirect URI can optionally allow wildcard matching. GitHub also says app owners can choose whether user tokens expire, with expiring tokens receiving a refresh token. The GitHub changelog announcement is especially relevant because GitHub accounts are often connected to package publishing, repository administration, CI secrets, issue trackers, and deployment systems. A compromised OAuth grant is not just another login problem; it can become a supply-chain problem.

What multiple redirect URIs change in practice

The biggest practical benefit is separation. A single OAuth app can now list production, staging, and approved local development callbacks without forcing teams to invent unrelated app identities. That makes reviews simpler: security teams can ask, "Does every redirect URI in this one list still serve a real product purpose?" Product teams can align documentation and support around one app name instead of explaining why users see different consent screens in different environments.

The feature also reduces pressure to use wildcards as a convenience shortcut. Wildcards can be useful for controlled preview environments, but they should be narrow and deliberate. A wildcard that covers too much of a domain can turn forgotten subdomains, misconfigured hosting, or abandoned preview URLs into authentication risk. The healthy default is to register exact callback URLs, use wildcards only when deployment architecture demands them, and review every wildcard whenever domains or hosting providers change.

For builders of desktop utilities and developer tools, multiple redirects also help clarify local callbacks. A CLI or desktop app may use localhost during a browser-based login flow, while the production web dashboard uses an HTTPS callback. Keeping those callbacks in one audited configuration is easier than scattering them across duplicated OAuth apps.

Why expiring tokens and refresh tokens matter

Long-lived access tokens are convenient until they are copied into a log file, leaked through a proxy, committed to a repository, or stored by a plugin that later becomes unmaintained. Expiring tokens limit the useful lifetime of a stolen access token. Refresh tokens introduce their own responsibility, because they must be stored securely and rotated carefully, but they give app owners a better path than permanent access.

Teams should not flip the switch casually. First, identify every client that depends on the OAuth app: web backend, mobile app, desktop app, CLI, background worker, support tooling, and scripts used by operations. Then confirm each client can handle token refresh, retry failed requests safely, and recover when a refresh token is revoked. Finally, update user-facing help text so people understand why they may occasionally need to reconnect an integration.

The GitHub OAuth authorization documentation remains the trusted technical reference for flow details. Use it alongside your own threat model. A developer productivity tool that only reads public repository metadata has a different risk profile than a deployment tool that can edit repositories or publish packages.

A practical audit checklist for teams

Start with inventory. List every OAuth app your organization owns, who owns it, which product it supports, and whether it is still used. For each app, record allowed redirect URIs, wildcard settings, requested scopes, token-expiration behavior, support contacts, and where client secrets are stored. If nobody can explain an app's purpose, disable it in a controlled way and watch for breakage before deleting it.

Next, reduce scope. Remove obsolete callback URLs, replace broad wildcards with exact URLs when possible, and split risky experimental environments away from production if they cannot meet the same controls. Confirm that staging callbacks do not point to shared or weakly protected environments. Review custom URL schemes used by mobile and desktop clients so they cannot be intercepted by another app on the same device.

Then test refresh behavior. Force token expiry in a test environment, confirm the app refreshes without losing user work, and verify that revocation produces a clear reconnect path. Log token-refresh failures without logging token bodies. Measure how many users will be affected before enabling expiration for a large installed base.

How this connects to software discovery and downloads

People usually evaluate software by features, price, and screenshots. OAuth behavior should be part of that evaluation, especially for tools that connect to GitHub, Google, Slack, cloud storage, or app stores. A trustworthy utility should explain why it needs account access, keep scopes narrow, support revocation, and handle token refresh without hiding errors.

That matters for BTTC's audience because many readers arrive while comparing apps, AI assistants, productivity tools, or developer utilities. Before downloading anything from a marketplace or vendor page, ask whether the tool's account connection model is transparent. If you are exploring new tools, browse the BTTC blog and software directory with this question in mind: does this product make secure access easy for ordinary users, or does it require blind trust?

FAQ

What did GitHub change for OAuth apps?

GitHub added support for multiple redirect URIs on OAuth apps and introduced an option for expiring user tokens with refresh tokens. GitHub says apps can register up to ten redirect URIs.

Should every OAuth app use wildcard redirect URIs?

No. Wildcards should be limited to cases where the deployment model truly requires them. Exact redirect URIs are easier to audit and usually safer.

Are refresh tokens automatically safer?

They can reduce the lifetime of stolen access tokens, but refresh tokens must be stored and rotated securely. Teams need implementation tests before enabling expiration for existing users.

Why should software users care?

OAuth grants often connect tools to valuable accounts. Users should prefer software that requests clear permissions, supports revocation, and explains how account access is protected.

Conclusion

GitHub's OAuth update is a good reminder that authentication settings are product infrastructure, not administrative trivia. Multiple redirect URIs can make real-world deployments cleaner, while expiring tokens can reduce exposure when implemented well. The right response is not panic; it is a disciplined audit of callbacks, scopes, token storage, and user recovery before the next integration or software download becomes part of your workflow.