GitHub OAuth apps: your single redirect URI is a wildcard

GitHub shipped three changes to OAuth apps on August 14: opt-in expiring access tokens with refresh, up to ten redirect URIs per app, and configurable wildcard matching on those URIs. The first two are conveniences. The third comes with a disclosure that belongs on your Monday list — GitHub OAuth apps with a single registered redirect URI have had wildcard matching on the whole time, and now you can see it.

What actually happened

Per GitHub's changelog, OAuth apps can opt into short-lived credentials by requesting the offline_access scope. You get an access token good for 8 hours and a refresh token good for 6 months; when the access token dies, you trade the refresh token for a new pair. That's the same pattern GitHub Apps have had for user access tokens, now available to classic OAuth apps.

Redirect URIs went from one to a maximum of ten per app, with an "Add redirect URI" button in app settings. That kills the common workaround of registering a separate OAuth app per environment just to have a working localhost callback.

Wildcard matching is the part to read twice. It lets one registered URI cover subdomains or paths — useful if you run per-tenant subdomains and don't want to register tenant-1234.yourapp.com a few thousand times. GitHub's note on existing apps: "Apps with only one redirect URI have wildcard matching enabled." It describes this as legacy behavior that is now visible and controllable, and asks developers to review their apps and turn it off if they don't need it. It applies to OAuth apps and to any GitHub App that had a single redirect URI registered.

These land in GitHub Enterprise Server 3.23.

Why OAuth redirect settings matter for your business

A permissive redirect is how an OAuth token walks out the door. The redirect URI is the one thing standing between an authorization code and an attacker's server. If matching is loose enough to accept a subdomain or path you don't control — a stale CNAME, a customer-supplied subdomain, an old preview environment, a user-content host — an attacker can craft an authorization request that lands the code somewhere they read. The account and the scopes are yours; the code isn't.

So go look at your apps today. Open every OAuth app and GitHub App your team owns, check the redirect URI list, and disable wildcard matching where you never asked for it. That's most of them, because most integrations were built with one exact callback URL and no idea a wildcard was implied. This is a ten-minute audit and it is the whole point of the announcement.

Then take the refresh tokens. An 8-hour access token is a materially smaller blast radius than a non-expiring one, and a non-expiring OAuth token in someone's .env file is the credential that shows up in breach writeups. Adding offline_access and a refresh flow is an afternoon of work in exchange for permanently shrinking what a leaked token is worth. Do it on new integrations by default.

And notice the shape of this. A vendor made an invisible default visible and asked customers to review it. That is the good version. The bad version is the default you never learn about. Keep an inventory of the OAuth apps that hold write access to your code, and re-read their settings when the vendor ships auth changes.

Sources: GitHub Changelog, August 14, 2026, GitHub Docs: Refreshing user access tokens.