自动化经典 PAT 和 SSH 密钥的 SSO 授权

企业管理员现在可以为 GitHub Enterprise Cloud 中组织的现有经典个人访问令牌（PAT）和 SSH 密钥自动化 SSO 授权，替代由开发者逐个组织手动授权。

如果你的企业有多个受 SSO 保护的组织，逐个组织手动授权凭据会造成摩擦和开销，导致使用长期令牌以避免轮换。

通过此版本，企业管理员可以选择启用一项新的企业设置，以允许通过使用 enterprise_credentials:write 权限的企业安装 GitHub App 进行凭据委托。这些 GitHub App 随后可以调用新 API，在单个请求中为最多 50 个组织批量授权一个经典 PAT 或一个 SSH 密钥。

它通过非秘密的令牌 ID 或 SSH 密钥指纹识别凭据，因此不会向 GitHub App 传递凭据秘密。在授予授权之前，它会确认每个目标组织属于该企业、凭据所有者属于每个组织，并且企业使用企业级 SSO。它会安全地跳过已存在有效授权的组织。

如果你的企业跨多个组织管理服务账号或自动化凭据的 SSO 授权，你可以让 GitHub App 在令牌轮换或新增一组组织时调用此 API。你可以这样做，而不是手动授权每个组织。

此功能现已面向 GitHub Enterprise Cloud 账户提供。了解有关企业凭据授权的 REST API 端点以及在企业上安装 GitHub App 的更多信息。

GitHub Enterprise Cloud 企业管理员可通过企业安装 GitHub App 和新增 API，批量授权现有经典 PAT 或 SSH 密钥，单次最多覆盖 50 个组织，减少逐组织手动 SSO 授权。

• GitHub Enterprise Cloud 企业管理员可通过企业安装 GitHub App 和新增 API，批量授权现有经典 PAT 或 SSH 密钥，单次最多覆盖 50 个组织，减少逐组织手动 SSO 授权。
• 原贴提到：Enterprise admins can now automate SSO authorization for existing classi
• 来源：github.blog

这是什么信号

这是 GitHub 官方 Changelog 释放的企业级身份治理信号：把 SSO 授权从开发者逐组织手动操作，升级为企业管理员可委托、可 API 批量执行的能力。核心不是多了一个按钮，而是把凭据授权纳入企业安装 GitHub App 的自动化链路。

为什么重要

多组织企业通常面临一个矛盾：安全上要求 SSO 保护，但逐组织授权成本高，团队为了省事会使用长期令牌并拖延轮换。新能力允许企业安装 GitHub App 获得 enterprise_credentials:write 权限后，调用 API 一次为最多 50 个组织批量授权经典 PAT 或 SSH 密钥，且只传 token ID 或 SSH 密钥指纹，不传凭据秘密。这能降低摩擦，同时保留秘密隔离和前置校验。

对谁有价值

• 企业管理员和平台工程团队：统一处理多组织 SSO 授权与凭据治理。
• 安全与合规团队：推动令牌轮换，减少长期凭据带来的风险。
• 维护服务账号或自动化凭据的团队：在轮换或新增组织时自动授权，而不是逐个手工操作。

可以怎么行动

先确认企业是否使用企业级 SSO，并梳理依赖经典 PAT 和 SSH 密钥的服务账号与自动化流程。然后评估是否创建或选用企业安装 GitHub App，授予 enterprise_credentials:write，并把批量授权 API 接入令牌轮换或组织新增流程。建议先用少量组织验证权限边界、失败处理和审计记录，再逐步扩大范围。

风险或限制

enterprise_credentials:write 属于敏感权限，企业安装 GitHub App 本身也必须严格管控，否则会扩大授权面。该能力聚焦经典 PAT 和 SSH 密钥，单次最多 50 个组织，并在授权前校验组织归属、凭据所有者归属和企业级 SSO；已有有效授权会被跳过。它不能替代身份治理策略，也不应被当作绕过 SSO 控制的手段，企业仍需处理调用失败、凭据轮换和审计留痕。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《自动化经典 PAT 和 SSH 密钥的 SSO 授权》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

• Allison 原帖