GitHub 自動化 PAT 與 SSH 金鑰的 SSO 授權：代理營運稽核
GitHub 於 2026 年 9 月 16 日宣布，GitHub Enterprise Cloud 管理員現在可為既有 classic personal access token 與 SSH 金鑰批次自動化 SSO 授權。企業可選擇啟用憑證委派，並由具有 enterprise_credentials:write 權限、安裝於企業層級的 GitHub App 執行。
新 API 可在一次請求中為一個 classic PAT 或 SSH 金鑰授權最多 50 個組織。GitHub 表示，請求以非敏感 token ID 或 SSH 金鑰指紋識別憑證，因此 GitHub App 不會收到憑證祕密。授權前，GitHub 會驗證目標組織屬於該企業、憑證擁有者屬於每個組織，且企業採用企業層級 SSO；已有有效授權的組織會被安全略過。
對營運代理測試、資料蒐集或區域監測儲存庫的團隊而言，這能縮短多組織憑證輪替窗口，但也可能讓錯誤的廣泛授權被自動重複。應把它視為高權限控制平面，而不是保留長期憑證的理由。
公開來源說明：GitHub，《Automate SSO authorization for classic PATs and SSH keys》，2026 年 9 月 16 日。
哪些改變、哪些沒有改變
過去，開發者或管理員常需逐一組織授權 classic PAT 或 SSH 金鑰，摩擦可能降低輪替頻率。新路徑允許企業啟用設定後，由核准的 GitHub App 批次執行授權。
此功能不會建立 token、不會揭露祕密，也不會取代儲存庫權限。SSO 授權與儲存庫存取是兩個不同門檻。帳號及儲存庫權限仍須滿足；代理路徑仍需通過 DNS、TCP、代理驗證、TLS 與 Git 或 API 操作。
不要把上線後的所有失敗歸因於 SSO。407 指向代理驗證，TLS 故障屬於傳輸驗證，應用程式的 403 則需結合權限和策略判斷。
代理自動化團隊為何需要關注
代理營運常把 SDK、瀏覽器檢查、區域測試夾具、合規規則與事故工具放在不同儲存庫，企業也可能隔離生產、預備與研究組織。批次授權可加速輪替，但也可能讓自動化憑證進入超出需求的組織。
採用前應盤點：
- 持有 classic PAT 或 SSH 金鑰的每個服務帳號；
- 每個工作負載真正需要的組織與儲存庫；
- 自動化使用的代理路徑與出口策略；
- GitHub App 安裝與權限負責人；
- token ID 或 SSH 指紋，絕不記錄祕密；
- 輪替、到期、撤銷與事故回應負責人；
- 缺少授權時能夠失敗關閉的證據。
使用代理憑證輪替指南將應用憑證與代理憑證分開，採用獨立輪替週期。
設計最小權限委派
建立工作負載身分到核准組織的明確白名單。不要因 API 支援大批次就預設「全部組織」。分離生產與非生產憑證，也不要將開發者個人 token 交給無人值守自動化。
委派 GitHub App 持有高權限企業許可，應限制能安裝、設定與呼叫的人員。記錄請求發起者、憑證非敏感識別、目標組織清單、逐組織結果、時間與變更單。記錄中不得出現 token 值、SSH 私鑰、代理密碼或工作階段 Cookie。
搭配GitHub Advanced Security 強制策略稽核，防止儲存庫或組織管理員靜默削弱敏感自動化程式碼的保護。
測試輪替且不產生繞過
採用分階段演練：
- 選擇非生產憑證及兩個測試組織；
- 依非敏感識別記錄目前授權；
- 透過正常流程輪替 PAT 或 SSH 金鑰；
- 僅對核准組織集合執行委派授權；
- 經指定代理測試一個允許的儲存庫操作；
- 測試未授權組織並確認失敗；
- 撤銷舊憑證並確認無法驗證；
- 確認沒有以直連作為回退；
- 比對應用稽核、GitHub App 活動與代理連線證據。
成功 clone 一次並不充分。還應涵蓋工作負載實際使用的 API 讀取、套件或發行資源、submodule 與可重用工作流程。不要為了讓無關測試通過而擴大權限。
若遇到特殊字元或序列化問題，可參考代理憑證編碼驗證，同時避免揭露祕密。
保護 PR 與工作流程邊界
自動化儲存庫可能接收不受信任的變更。PR 不得呼叫委派 API、選擇任意組織、讀取 classic PAT 或存取 SSH 私鑰。應把委派放進受保護工作流程，限制輸入與環境，並依風險採用獨立核准。
掃描提交、工作流程記錄與產出物中的意外憑證。GitHub PR 祕密阻擋指南提供針對代理使用者名稱、密碼與 token 的失敗關閉審查方式。
驗收清單
- 企業憑證委派已明確啟用且有負責人；
- GitHub App 僅持有必要企業權限；
- 每個工作負載都有組織白名單；
- 生產與非生產憑證分離；
- 授權只使用 token ID 或 SSH 指紋，不傳祕密；
- 企業歸屬、成員關係與 SSO 前提均已驗證；
- 略過既有授權的結果可稽核；
- 驗證後撤銷舊憑證；
- 未授權組織能夠失敗關閉；
- 已證明指定代理路徑，禁止直連回退；
- PR 無法呼叫委派或變更目標清單；
- 記錄不含 token、私鑰、代理密碼或 Cookie；
- Global、North America、Europe 與 APAC 採用相同控制標準。
常見問題
GitHub App 會收到 classic PAT 或 SSH 私鑰嗎？
GitHub 表示，新 API 使用非敏感 token ID 或 SSH 指紋識別憑證，因此不會把憑證祕密傳給 App。
SSO 授權等於儲存庫權限嗎？
不是。它只讓憑證通過 SSO 組織門檻，最終仍由憑證擁有者與儲存庫權限決定存取範圍。
一個請求可以授權所有組織嗎？
API 單次最多支援 50 個組織，但營運策略應只授權工作負載必要的組織。
這是否表示應繼續使用長期 classic PAT？
不是。它可降低輪替摩擦，但支援時仍應優先使用短期、窄範圍憑證。
合規說明
只對獲准管理的企業帳號、組織與儲存庫使用憑證委派。保留變更核准、稽核、最小權限與撤銷程序。不得使用委派憑證或代理路由規避存取控制、速率限制、服務條款或地區要求。
