Security updates for apps and API access

Today GitHub is enforcing two new security improvements. First, signing into GitHub Apps and OAuth Apps that are private or owned by Enterprise Managed User (EMU) accounts is now restricted unless you are a member of the organization or enterprise that owns the application. Second, we have tightened the definition of internal visibility when calculating the access an SSO-authorized token has within a multi-organization enterprise.

These updates block some access patterns that a few developers (<0.05%) relied on, often unknowingly. We have temporarily exempted applications and enterprises that appeared to depend on this access, and have emailed these application owners and administrators with details about how to update their use to avoid breakage.

Application authorization updates

Application visibility and EMU ownership is now taken into account when deciding who can sign in to a GitHub App or OAuth app. As a result, to sign into an app, users must now be a member of the enterprise if it is internal, or the owning organization if it's private. GitHub Apps that are private and owned by a user can only ever be signed into by the user that owns the app.

Prior to this update, users were able to grant any application permissions against their user account by signing into it. This only gives the application access to the user account and does not grant the user any access to data in GitHub. However, app developers who did not validate the identity of a signed in user may have assumed that because the user signed in they are a valid user of the application, and gave the user access to data protected by the application. We are making this change to application authorization so that it aligns with developer expectations in order to reduce the impact of insufficient authorization in applications.

Some developers took a dependency on this access pattern and have a reliance on external users accessing their application despite it being internal or private. Applications with 50 or more external users signing into them in the last year have been exempted from this update, and the owners have been emailed with the details about this exemption and when it expires. If you find that some users are no longer able to sign in to your application because of this update, you need to change your application in one of the following ways:

• If your app is owned by an EMU account but needs to be accessed by users outside of your enterprise, you need to recreate the application outside of your enterprise.
• If your app is private and needs to be accessed by members of your enterprise, transfer it to your enterprise. This makes it internal.
• If users outside of your organization and enterprise need to access the app, make it public.
• If you own the app on your user account but want members of a specific organization or enterprise to access it, you need to transfer it to that account.

This update does impact private GitHub apps on GHES and will be part of the GHES 3.19 release. It does not impact internal GitHub Apps owned by the enterprise account on any product line.

For more information, see our documentation about:

• OAuth apps best practices
• GitHub App visibility

Token authorization in multi-organization enterprises

The internal or "innersource" model allows a member of an enterprise to read resources (specifically repositories, packages, and projects) set to internal visibility in organizations within the enterprise even if they are not a member of the owning organization nor granted explicit access to the resource. If a classic personal access token (PAT) or app token is authorized via SSO for one organization in an enterprise, it is also able to access all internal resources in the enterprise as long as the token is created with the required permissions, such as the repos or read:audit_log scopes.

A bug in how internal was calculated for organizations and enterprises that enforce single sign-on (SSO) was found and fixed, which will reduce the access of some tokens which were being used to access organizations they were not explicitly authorized for. Resources without a visibility setting (metadata and resources that are not repositories, packages, or projects) were considered by the SSO check to be internal. This meant that instead of blocking access to the resource immediately, the resource's authorization checks were allowed to run. The result was that users who were granted access to those resources could access those resources with a token that was not authorized for the organization that owned the resource, as long as the token was authorized for another organization in the enterprise.

The most commonly accessed data as a result of this bug were:

1. Listing the names of repositories
2. Listing organization members and collaborators
3. Listing members of teams

This bug did not result in users being able to access data they were not authorized to access. However, it did mean that a stolen token would have a wider blast radius than expected because it was able to access data that the token's owner had not intended it to access. It also meant that some developers took a dependency on this access to more easily fetch data from GitHub across their enterprise's organizations, particularly using GraphQL, without needing to authorize their token for hundreds of organizations.

Updating credential authorizations

Enterprises that appear to have a dependency on this bug (10 API calls in the last 30 days that will be impacted by this update) for automation have been exempted from this update and the enterprise owners have been emailed. Contacted enterprise owners will find a list of tokens that would have been impacted by this update, as well as a list of the organizations and APIs that were successfully accessed via this bug. They will have the choice of enforcing the update immediately and breaking access for those tokens or delaying enforcement while they authorize those tokens for access to the correct organizations.

Users should proactively update SSO credential authorizations for tokens that are expected to operate in many organizations within your enterprise. Each organization will need to be SSO authorized individually.

Because GHES does not use SSO credential authorization, this bug is not present there and no changes will occur due to this update.

For more information, see our documentation on SSO authorization of credentials.