GitHub 憑證事件回應：按 token 類型撤銷，避免整批清空

先分清 deauthorization 與刪除 credentials#

GitHub 文件將兩種動作分開。名稱相近，但對使用中的流程影響不同：

SSO authorization 被撤銷後，使用者要依 GitHub 的要求重新建立 credential 並重新授權；原本的 credential 對非 SSO 資源的權限不會因為這個動作自動變成另一種 scope。刪除 credentials 則是不可逆的破壞性操作，應先列出會受影響的自動化與部署流程。

token 類型要和使用情境一起盤點#

官方 REST API 的 credential_type 包含 classic_pat、fine_grained_pat、ssh_key 和 oauth_app_token。Changelog 也以 personal access tokens、SSH keys、OAuth app tokens 與 GitHub App user access tokens 說明這次的管理範圍。實際可選的類型會依 enterprise／organization endpoint 和帳號形態而不同，不要把一個 API enum 當成所有 credential 的完整清單。

事件回應時至少要把這些使用情境列出來：

• CI 或部署腳本使用的 PAT、OAuth App token 或 GitHub App user access token。
• 開發者透過 SSH key 取用 repository 的方式。
• 由 GitHub App installation token 執行的服務，以及 workflow 內的 GITHUB_TOKEN。
• 由外部服務保存的 refresh token、secret 或 deploy key。

GITHUB_TOKEN、GitHub App installation token、deploy key 等不是這個 enterprise credential 管理動作可以直接當作同一類 credential 處理的對象。要處理它們，仍需回到各自的 repository、App、workflow 或外部 secret 管理流程。這也是為什麼事件回應不能只看 UI 上的一個總數。

如果你的 OAuth App 還要支援 token 輪替，可以再對照 GitHub OAuth App 的 callback 與 refresh token 設定；那篇處理的是登入流程，不是這次的 enterprise incident response。

用最小爆炸半徑安排處理順序#

可以按下面順序執行，並把每一步留下證據：

1. 先從 audit log、服務擁有者和 secret inventory 確認疑似外洩的 credential type、user 與 enterprise／organization 範圍。
2. 如果只是 SSO 授權不再可信，優先選擇單一 token type、單一 user 或單一 organization 的 deauthorization。
3. 如果 credential 內容已經暴露，且帳號情境支援刪除操作，再評估 Delete keys and tokens；先準備新 credential、部署窗口和回復步驟。
4. 排查 CI、部署、Git over SSH 和外部整合，因為撤銷不會替你更新第三方 secret store。
5. 操作完成後檢查 audit log 與通知，確認 asynchronous job 已被接受並追蹤結果，而不是只看到按鈕消失。

若要用 REST API 做 enterprise 級、單一類型的授權撤銷，官方範例的非破壞性參數如下。revoke_credentials: false 代表先撤銷授權；仍應使用專門的 break-glass 管理憑證，不要用可能就在這次事件中的 PAT。

1
curl --fail-with-body --request POST \
2
  --url "https://api.github.com/enterprises/ENTERPRISE/credential-authorizations/revoke-credential-type" \
3
  --header 'Accept: application/vnd.github+json' \
4
  --header "Authorization: Bearer ${BREAK_GLASS_TOKEN}" \
5
  --header 'X-GitHub-Api-Version: 2026-03-10' \
6
  --data '{"credential_type":"classic_pat","revoke_credentials":false}'

GitHub REST API 會以 202 Accepted 表示 revocation request 已排入背景工作；這不等於所有受影響流程已經完成切換。若呼叫 API 的 PAT 正好是被撤銷的類型，它本身也可能失效，因此要事先準備不在事件範圍內的管理憑證。

事件後不要只看 token 是否消失#

撤銷或刪除後至少再檢查三件事：

• audit log 是否出現對應的 org_credential_authorization、personal_access_token 或 oauth_access 事件。
• 被影響的使用者是否收到通知，並知道要重新建立哪一種 credential。
• workflow、部署平台、package registry、SSH client 和外部 secret manager 是否已更新新值。

GitHub Actions cache 也不應保存 token 或 credential；如果事件是由 CI 產物或快取暴露引起，可以一起檢查 Actions cache 的 restore-keys 與信任邊界，避免只撤銷 token 卻留下同一個暴露入口。

結論：撤銷範圍要和證據一樣精確#

按 token 類型撤銷讓 GitHub 事件回應多了一層可控範圍，但它不會自動盤點外部 secrets，也不會涵蓋所有 GitHub token。先分清 SSO deauthorization、刪除 credentials、organization／enterprise 範圍和非同步完成狀態，再決定要切斷哪一類憑證；這比一次清掉所有登入方式更容易保留可用的復原路徑。

常見問題#