New OAuth App features: Multiple redirect URIs, wildcarding, and token expiration and refresh

[hpsin]

🏷️ Discussion Type

Feature Announcement

💬 Feature/Topic Area

Apps

Body

We've shipped multiple updates to the OAuth and GitHub App platforms to help developers build more secure applications and handle more complex scenarios. See the changelog for more details.

What's new:

1. OAuth apps now support token expiration and refresh. Either as an app setting or per-request via the offline_access scope, OAuth apps can now get a short lived (eight hours) token and a refresh token to use when the access token expires. Learn about the new tokens and scope in the docs.
2. OAuth apps now support up to 10 redirect URIs instead of the single-URI limitation previously in place.
3. Both GitHub Apps and OAuth apps can enable wildcarding on a per-redirect-URI basis. This is not a best practice and we recommend against using it.

App developers should review their redirect URIs - if your app had only a single redirect URI registered, then it is and has been enabled for wildcard access since creation. If you do not require this wildcard access, you should disable it.

Please let us know your feedback, questions, or bug reports here. Thanks for building an app on GitHub!

[korvahannu]

@hpsin was this reverted? We no longer have the option to set wildcard matching.

[hpsin]

Unfortunately yes, we had an issue and are in the middle of fixing it, should be reenabled tomorrow. If you had any issues with this being rolled back, please file a support ticket and we can help fix it.

[korvahannu]

@hpsin Thanks for the quick reply! No issues, but we were about to use this wildcard feature when it suddenly disappeared 👍

Quick question: The recommendation is to not use wildcards. But let's say we own somedomain.com and we have many customer specific deployments i.e. <somecustomer[1..100]>.ourdomain.com. We use the OAuth flow. Without wildcards, we need to create a separate callback service that redirects users to correct places. So the question is, against what is recommended, are there any negatives of using wildcards in this case as opposed to having a separate callback service?

[hpsin]

It's now re-enabled. Sorry about that!

And yes this is what the wildcard is intended for, precisely.
The downside of this is that it's not a scoped wildcard match - it'll match Foo.somecustomer1.ourcompany.com/a/long/path as well.

The downside here is risk - you have to do more diligence about your app architecture to make sure an expansion of the subdomains and path can't become something risky.

[saivamshidanthoju]

These are great improvements, especially support for refresh tokens and multiple redirect URIs. Both have been long-standing pain points when managing development, staging, and production environments. The per-URI wildcard option is a nice addition, but I appreciate the emphasis on using it only when necessary. Thanks for continuing to modernize the OAuth platform.

[jamalkamaladdin]

The line worth re-reading: if an app has a single redirect URI, wildcard matching has been on since the app was created. So for most existing apps this isn't an opt-in, it's an opt-out nobody knew they had.

Is that state readable anywhere outside the settings UI? Clicking through app settings doesn't scale, and this is the kind of thing you want to assert in CI rather than remember to check.

[saivamshidanthoju]

Good point. Having this exposed through an API or CLI would make it much easier to audit applications at scale. Relying on the settings UI doesn't work well when managing many OAuth apps, and being able to verify whether wildcard matching is enabled in automation or CI would improve security and reduce configuration drift.

[hpsin]

Agreed. We have APIs for app registration management on our near-term backlog but no concrete dates to share just yet. I wish we had something better for you here - I know "terraform for apps" is high on the list of requests and we would love to get there.