GitHub Can Now Authorize One Credential Across 50 Organizations

GitHub Enterprise administrators can now automate SSO authorization for a classic personal access token or SSH key across as many as fifty organizations. The API accepts a credential identifier or SSH fingerprint; it does not require the secret itself.

This removes a real service-account headache. Rotating one credential no longer requires a person to visit every organization and repeat an authorization flow. It also gives the GitHub App performing the operation a new form of delegated power.

The secret is not the only sensitive object

It is good that the API does not receive the token value or private SSH key. But an app with enterprise_credentials:write can expand where an existing credential works. That authorization is valuable even without knowledge of the secret.

I would therefore separate the system that generates or stores credentials from the system that authorizes them. The latter should receive only the identifier, intended organizations, owner, expiration, and change request. Its installation and private key deserve the same controls as other enterprise identity automation.

Bulk authorization needs bulk revocation

A service account should have a declared organization set, not “whatever accepted the last run.” Reconciliation should compare desired and actual authorization, remove organizations that are no longer in scope, and record every change.

Rotation is a transaction: create the replacement, authorize it, verify the real client path, switch consumers, and revoke the old credential. A successful API response at step two is not proof that a deployment host loaded the new key.

Classic credentials remain the compatibility path

The feature specifically helps classic PATs and SSH keys. Where a GitHub App or fine-grained token can provide narrower repository access and shorter-lived credentials, I would still prefer that design. Some automation, tooling, and multi-organization workflows do not fit it yet; those are the cases where centralized authorization is valuable.

Enterprises must opt in. Before enabling it, I would require an owner, a maximum organization count, an expiration policy, and alerts for authorization changes. Convenience is the point, but convenience should not quietly turn one old token into an enterprise-wide credential.

Source

GitHub: automate SSO authorization for classic PATs and SSH keys.