Three changes landed for GitHub OAuth apps on 14 August. Two are conveniences you will be glad of. The third is a default that was already true, is now visible, and deserves twenty minutes of your attention today.
Start with that one: every existing app with a single redirect URI has had wildcard matching automatically enabled. GitHub is not introducing new behaviour — it is surfacing legacy behaviour that was previously implicit. Which means the surprise is not what changed, it is what has been true all along.
The wildcard default, and why to look now
Both OAuth apps and GitHub Apps now support wildcard matching for redirect URIs, so a redirect can go to related subdomains or paths rather than one exact address.
GitHub's own warning is unambiguous: wildcard matching can be abused if the site being redirected to does not have strong control over its routes. A wildcard on a domain where anyone can create a page is a route for sending an authorisation code somewhere it should not go.
GitHub's advice is to review and disable wildcard matching where it is not needed. For a single-redirect-URI app it is almost certainly not needed, and turning it off is the cheapest security action available to you this week.
Expiring tokens: 8 hours and 6 months
OAuth apps can now use short-lived access tokens that last 8 hours, paired with refresh tokens valid for 6 months. Developers enable this with the offline_access scope, or by configuring the app to always use expiring tokens.
Short-lived tokens are on by default for all new applications. Existing apps are not forced onto them, which is the right call — a token lifetime change breaks integrations that assumed a token was permanent.
The security argument is simple arithmetic. A non-expiring token that leaks is a permanent credential in someone else's hands. An 8-hour token that leaks is a problem measured in hours. That is the entire case, and it is a good one.
Ten redirect URIs
Apps can register up to 10 redirect URIs instead of a single callback URL. That removes the standard workaround of registering separate app instances for staging, preview and production.
It is a small change with a direct security benefit: teams that previously reached for a wildcard to cover several environments can now enumerate them instead. Explicit URIs beat a pattern that also matches things you did not think of.
How to adopt this without an outage
GitHub's suggested path is a gradual one, and it is worth following rather than flipping a switch.
- Test token expiration using the offline_access scope on some clients before forcing all of them onto it
- Confirm your refresh logic actually works — an untested refresh path is the thing that fails at hour eight, in production, on a weekend
- List your redirect URIs explicitly, up to ten, rather than relying on a wildcard
- Then disable wildcard matching where you no longer need it
- If you run GitHub Enterprise Server, note these features arrive in 3.23