Updated Oct 14
GitHub Apps gain narrower repository permissions and staged token rotation

Platform Governance

GitHub Apps gain narrower repository permissions and staged token rotation

GitHub added fine‑grained permissions for repository creation and installation membership, relaxed approved‑app installation rules, and introduced offline_access for staged migration to expiring user tokens.

Repository creation no longer requires broad administration access

GitHub's [October 13 release](https://github.blog/changelog/2026‑10‑13‑github‑app‑improvements‑for‑least‑privilege‑and‑management/) adds `repository_creation:write` for GitHub Apps and fine‑grained personal access tokens. It lets the caller create a repository in the granting account without `repository_administration:write`, which also covers powers such as deletion and transfer. An organization administrator still has to install an app that requests the new permission. The narrower grant reduces the privilege attached to repository provisioning; it does not let an app bypass installation approval or organization policy. Before changing an existing integration, inventory which administration endpoints it really calls. Replace the broad permission only after tests confirm the app does not depend on another administration capability.

Installation membership can be automated with repository scope

A second permission, `installation_repositories:write`, allows an authorized caller to add or remove a repository from an app installation. GitHub says the related APIs previously required the coarse classic `repo` scope. For a user‑held fine‑grained token, the caller must also be an organization owner or an administrator of the affected repository. The permission therefore narrows the token while retaining a human role check. Repository administrators can also add their repositories to an app already approved and installed by the organization owner, even when that app has organization‑level access. An owner can preserve tighter control by restricting installation changes to organization owners.

offline_access enables a per‑authorization token migration

GitHub Apps now accept the `offline_access` scope during user authorization. The [token‑refresh documentation](https://docs.github.com/en/apps/creating‑github‑apps/authenticating‑with‑a‑github‑app/refreshing‑user‑access‑tokens) says this produces an expiring user access token and refresh token for that authorization even if the app has not globally enabled token expiration. That supports a staged migration: test rotating tokens with selected users before changing every authorization. The current documented lifetimes are eight hours for the access token and six months for the refresh token. Using a refresh token invalidates the old access token and refresh token. The scope does not add app permissions. A user token remains limited by the intersection of the app's grants, the installation's repositories and the user's own access.

Private‑app discovery and credential management also changed

GitHub Apps can now retrieve details about private or internal apps when the apps share qualifying ownership: the same organization, the same enterprise for internal apps, or an enterprise‑to‑organization relationship described in the release. Public app details remain broadly accessible. This enables inventory automation without making private apps public. It does not grant access across unrelated owners or enterprises. Test the exact ownership relationship before depending on the API for a complete catalog. GitHub also moved client secrets and key pairs into a dedicated Credentials tab, preparing the interface for planned workload‑federation credentials. The interface change does not rotate or revoke credentials by itself.

Migrate one permission and one token path at a time

For an existing app, capture its current permissions, installation scope and token‑expiration setting. Introduce the narrow repository permission in a test installation, exercise every required endpoint and verify denied operations fail as expected. For token rotation, request `offline_access` for a small cohort, store the replacement refresh token atomically and test expiry, refresh, revocation and reauthorization. Do not log user tokens or refresh tokens. GitHub says most changes reach GitHub Enterprise Server 3.24, while `offline_access` arrives in 3.23, so mixed deployments need version‑aware behavior. These changes make least‑privilege migration easier, but they do not prove an app's current permissions are minimal. Follow [GitHub's OpenTools organization page](https://opentools.ai/organizations/github) for material platform changes. *Image: Real screenshot of GitHub's official October 13 GitHub Apps release page. OpenTools captured the source page without generative alteration or artificial upscaling.*

Share this article

PostShare

Related News