Bulk authorization for enterprise credentials

GitHub has introduced an option for enterprise administrators to automate single sign-on authorization for existing classic personal access tokens, or PATs, and SSH keys. The capability is available for organizations using GitHub Enterprise Cloud and is intended for enterprises that manage credentials across multiple SSO-protected organizations.

Under the new process, an enterprise-installed GitHub App can call a new API to authorize a classic PAT or SSH key for multiple organizations in a single request. The request can cover up to 50 organizations, removing the need for developers to repeat the authorization process separately for every organization.

An alternative to manual organization-by-organization work

GitHub said that manually authorizing credentials one organization at a time creates friction and administrative overhead when an enterprise has several organizations protected by SSO. That burden can also encourage the use of long-lived tokens to avoid repeated authorization and rotation work.

The new capability moves that administrative task to an automated enterprise workflow. Rather than asking developers to authorize a credential whenever it needs access to another organization, an enterprise can use an approved GitHub App to apply authorization across the relevant organization set.

Enterprise opt-in and GitHub App permission

The feature is not enabled automatically by the announcement. Enterprise administrators can opt in to a new enterprise setting that permits credential delegation through GitHub Apps installed on the enterprise.

The GitHub App must have the enterprise_credentials:write permission to use the new authorization API. This permission provides the mechanism for the app to submit bulk authorization requests on behalf of the enterprise, while the enterprise setting controls whether that delegation is allowed.

Credential secrets are not passed to the app

The API identifies a classic PAT by its non-secret token ID and identifies an SSH key by its fingerprint. GitHub said this means credential secrets do not need to be passed to the GitHub App during the authorization request.

Using identifiers rather than secret values allows an automation system to select the credential that should be authorized without placing the token or private-key material in the app workflow. The source describes the token ID and SSH fingerprint as the identifiers used for this purpose; it does not indicate that the API creates, rotates, or reveals credentials.

Checks before authorization

Before granting authorization, GitHub confirms that every target organization belongs to the enterprise and that the credential owner belongs to each organization. It also verifies that the enterprise uses enterprise-level SSO.

The API safely skips organizations where an active authorization already exists. This allows an enterprise automation process to include a broader organization list without attempting to replace an authorization that is already active.

Use cases for service accounts and automation

GitHub positioned the capability for enterprises that manage SSO authorization for service accounts or other automation credentials across many organizations. An enterprise can have its GitHub App call the API when a token is rotated or when new organizations are added to the set requiring access.

That workflow can reduce the manual steps associated with credential changes and organization expansion. GitHub said the feature is available now for GitHub Enterprise Cloud accounts and directed administrators to its documentation for the REST API endpoints for enterprise credential authorizations and for installing a GitHub App on an enterprise.

Sources

• GitHub ChangelogAutomate SSO authorization for classic PATs and SSH keys