GitHub OAuth Apps Get Multi-Redirect URIs, Token Refresh, and Wildcard Matching

GitHub has shipped three security-focused updates to its OAuth app and GitHub App platforms. OAuth apps can now register up to 10 redirect URIs, opt into short-lived 8-hour access tokens paired with 6-month refresh tokens, and enable wildcard matching on each redirect URI. All new OAuth apps get expiring tokens by default. The changes are also coming to GitHub Enterprise Server 3.23.

What happened

Feature	Detail
Max redirect URIs per OAuth app	10
Access token lifetime (short-lived)	8 hours
Refresh token lifetime	6 months
Short-lived tokens for new apps	Enabled by default
Enterprise Server version	3.23

GitHub has updated both its OAuth app and GitHub App platforms with three distinct changes aimed at tightening security and reducing the overhead of managing apps across multiple environments.

Rotating access tokens for OAuth apps

OAuth apps can now request short-lived tokens during the user authentication flow. Instead of a long-lived token that never expires, the app gets an access token valid for 8 hours and a refresh token valid for 6 months. When the access token expires, the app exchanges the refresh token for a new token pair.

Developers have two ways to enable this:

1. Include the offline_access scope in the authentication request. This triggers the short-lived token pattern and is the recommended path for testing and gradual rollout.
2. Set the app registration to always use short-lived tokens. This forces older clients to update and ensures every client gets a short-lived token, with no opt-out possible at the client level.

Short-lived tokens are on by default for all new OAuth apps. If your authentication SDK does not yet support the refresh token flow, GitHub says you can disable this while you update the SDK.

Up to 10 redirect URIs per app

Previously, an OAuth app could only register a single callback URI, which pushed teams to create separate app registrations for staging, production, and other environments. Apps can now register up to 10 redirect URIs. A new “Add redirect URI” button appears in application settings to manage them. This covers the most common multi-environment and multi-domain setups from a single registration.

Wildcard matching: useful but risky

Both OAuth apps and GitHub Apps can now enable wildcard matching on each configured redirect URI. A wildcard match lets GitHub redirect an authorization code to any URL that matches a subdomain or additional path off the registered URI. The practical use case is multi-tenant apps where each customer gets a subdomain, without needing a separate registered URI per tenant.

GitHub’s own warning here is worth quoting directly: wildcard matching can be abused if the site being redirected to does not have strong control over its routes, for example if it hosts user-generated content.

There is also a legacy behavior to be aware of. Any OAuth app or GitHub App that had only one redirect URI registered already had wildcard matching enabled silently. That behavior is now visible and controllable in settings. GitHub is asking developers to review their apps and disable wildcard matching if they do not need it.

Why it matters

Long-lived OAuth tokens are a common attack surface. If a token leaks, it is valid until the user revokes it manually. The 8-hour window cuts that exposure significantly. The refresh token flow is a pattern already standard in OpenID Connect and modern auth libraries, so most stacks already support it or have it on the roadmap.

The multiple redirect URI feature is less dramatic but practically useful. Dev, staging, and production environments sharing one app registration means fewer credentials to manage and less drift between environments. Teams building on platforms like web development stacks that deploy to multiple environments will feel this immediately.

The wildcard URI revelation is the most consequential piece for teams who have not actively managed their GitHub app settings. A single-URI app has had wildcard matching on this whole time. If that app’s domain hosts user content or has loose routing, there is a real redirect-hijacking risk to evaluate.

Our take

The token rotation change is straightforwardly good. Eight hours is a reasonable session window for developer tooling, and six months on the refresh token gives enough headroom for infrequent users without creating permanent credential exposure. The default-on behavior for new apps means teams do not have to remember to opt in, which is the right call.

The wildcard URI disclosure is the part that needs immediate attention. Most teams do not audit their GitHub app settings regularly. The fact that this was always on for single-URI apps, invisibly, is the kind of thing that surfaces in a security review. Go check now. Our AI integration work almost always involves OAuth flows, and we have seen firsthand how easy it is to leave default settings in place longer than you should.

If you are tracking how GitHub continues to tighten its platform security, our coverage of GitHub’s registry and SBOM work is worth reading alongside this.

What to do about it

1. Open your GitHub OAuth app settings and check whether wildcard matching is enabled on any redirect URI. Disable it if you do not need subdomain or path matching.
2. Check whether your authentication SDK supports the refresh token flow. If it does, add the offline_access scope and test the short-lived token path in a staging environment.
3. Once tested, set the app registration to always use short-lived tokens to enforce the change for all clients.
4. If you run multiple environments (dev, staging, prod), consolidate them under a single app registration using the new multi-redirect URI support instead of maintaining separate apps.
5. If you run GitHub Enterprise Server, plan for these features in version 3.23.

Audit your redirect URIs today. A 10-minute settings review is cheaper than a security incident.

Source: GitHub Changelog