Two new repository fine-grained permissions have been added, available to both fine-grained PATs and GitHub Apps.<\/p>\n
- \n
repository_creation:write<\/code>: Allows the caller to create a repository in the account where it’s granted.<\/li>\ninstallation_repositories: write<\/code>: Allows the caller to add or remove that repository from an installation in the organization.<\/li>\n<\/ul>\n<\/p>\n
Create a repository without
repository_administration<\/code><\/span><\/a><\/h3>\nYou can now use the
repository_creation:write<\/code> permission to create repositories without needing the broaderrepository_administration:write<\/code> permission.<\/p>\nPreviously, an app or PAT needed
repository_administration:write<\/code> to create a repository. That permission also grants other repository administration features like deletion and transfer. This could lead to administrators rejecting apps, banning PATs with this permission, or having to accept the over-privilege risk.<\/p>\nThe new permission supports a least-privilege approach by granting only the ability to create repositories. When the repository is created, the app or user that created it will be given access to it. An app using this permission still requires an organization administrator to install the app.<\/p>\n
See the API docs for repository creation in organizations<\/a>, from a template<\/a>, for the current user<\/a>, with a fork<\/a>, and via GraphQL<\/a>.<\/p>\n
Manage installation repositories with an app or fine-grained PAT<\/span><\/a><\/h3>\n
The Add a repository to an installation organization-level API<\/a> and its corresponding removal API<\/a> now support GitHub Apps and fine-grained PATs. Previously, these APIs only supported the coarse-grained
repo<\/code> scope.<\/p>\nThese APIs support a new repository-level fine-grained permission:
installation_repositories:write<\/code>. Having this permission on a repository allows the caller to add or remove that repository from any installation in the organization. If the caller is a user, they must also be an organization owner or an administrator on the repository in question.<\/p>\nThis allows organizations to build automation that controls which repositories are accessible to which GitHub Apps without relying on an administrator’s PAT with broad permissions.<\/p>\n
Repository administrators can more easily add approved GitHub Apps to repositories<\/span><\/a><\/h2>\n
Historically, all apps that requested organization-level access were blocked from being installed on a repository by a repository administrator, no matter what. This restriction has been relaxed in the case where the app is already installed in the organization, meaning it’s been approved by an organization owner for that organization-level access. Repository administrators can now edit an existing installation to add their repositories to an app without requiring organization owner approval. The apps already have the organization-level access, so adding them to another repository in the organization doesn’t increase that access or give the repository administrator additional privileges.<\/p>\n
With the addition of the
repository_creation<\/code> permission above, there are now three sensitive permission sets that require organization owner approval:<\/p>\n- \n
- All organization-level permissions<\/li>\n
- Repository administration<\/li>\n
- Repository creation<\/li>\n<\/ul>\n
This change allows repository administrators to better use apps that are already approved for use in their organization.<\/p>\n
If you’d like to prevent repository administrators from adding apps to their repositories, see “Restricting GitHub App Installation to Organization Owners<\/a>” in the docs. For more details on adding an app to a repository, see “Installing a GitHub App<\/a>“.<\/p>\n
Use
offline_access<\/code> with GitHub Apps to gradually reenable short-lived, rotating tokens<\/span><\/a><\/h2>\nGitHub Apps now support the
offline_access<\/code> scope, like OAuth apps. While GitHub Apps use short-lived, rotating tokens by default, some developers have disabled expiration for convenience and now struggle to reenable it.<\/p>\nThis support helps app developers gradually migrate to expiring user access tokens. Developers can enable token expiration for testing and rollout without having to switch every user to expiring tokens at the same time, which would break existing clients.<\/p>\n
When
offline_access<\/code> is requested, the app receives a refresh token in addition to the expiring access token. It only changes that specific authentication and doesn’t impact future sessions.<\/p>\nThe
scope<\/code> parameter is still otherwise unused for GitHub Apps—permissions are still statically selected on the application registration. For more details, see “Refreshing user access tokens<\/a>“.<\/p>\nThis is available in GHES 3.23.<\/p>\n
GitHub Apps can fetch details about other private and internal apps<\/span><\/a><\/h2>\n
GitHub Apps can now use the Get an app API<\/a> to fetch details about private and internal GitHub Apps, as long as they share some ownership.<\/p>\n
The permitted access patterns are:<\/p>\n
- \n
- Public apps:<\/strong> Any other app can fetch the app’s details. This was the previously enabled level of access.<\/li>\n
- Apps in the same organization:<\/strong> Apps can fetch each other’s details regardless of visibility, if they share the same owner.<\/li>\n
- Internal apps in the same enterprise:<\/strong> An internal app’s details can be fetched by another app in the same enterprise, even across organization boundaries.<\/li>\n
- Enterprise-to-organization access:<\/strong> An enterprise-owned app can fetch details about apps owned by organizations in the same enterprise.<\/li>\n<\/ol>\n
This enables organizations and enterprises to automate more of their GitHub App auditing and administration.<\/p>\n
For more details about app visibility, see “Making a GitHub App public or private<\/a>“.<\/p>\n
A new credential management tab for GitHub Apps<\/span><\/a><\/h2>\n
GitHub App credentials are now managed from a dedicated Credentials<\/strong> tab instead of appearing inline with the rest of the app configuration. This makes credentials easier to find and manage, and sets aside space for our upcoming workload federation<\/a> credentials.<\/p>\n
<\/p>\n
- Apps in the same organization:<\/strong> Apps can fetch each other’s details regardless of visibility, if they share the same owner.<\/li>\n
- Public apps:<\/strong> Any other app can fetch the app’s details. This was the previously enabled level of access.<\/li>\n