識別支援的存取權杖

8 分鐘

您會在此處了解不同的 GitHub 存取權杖、其應用、限制和速率限制。

授與公司內部使用者存取權時，驗證非常重要。使用者存取權限應具有嚴格的範圍，並且只包含使用者完成任務所需的内容。瞭解不同的存取權杖十分重要，因為您可以協助指導公司內部的使用者，針對其使用案例採用最佳選項。

GitHub 使用各種權杖，讓使用者驗證他們所需執行的不同活動。通常，這些不同的權杖簡單明瞭，而且很容易就能知道要使用什麼權杖。但有時候，使用多個權杖也可達成相同結果，因此權杖的選擇歸根究柢就是在好、更好和最好的選項之間做選擇。在這些情況下，請務必識別 GitHub 權杖的特性，以及正確設定權杖存取範圍的方法。以下是各種可用存取權杖的清單：

GitHub 個人存取權杖
GitHub 使用者對伺服器權杖
GitHub 伺服器對伺服器權杖
OAuth 存取權杖
重新整理權杖

請務必鼓勵開發小組使用具有正確範圍的權杖，以便在發現安全漏洞時快速降低風險。讓我們來進一步了解這些存取權杖。

個人存取權杖

個人存取權杖 (PAT) 是用密碼驗證 GitHub 的替代方法。為了在存放庫中進行推入和提取，GitHub 需要驗證使用者存取權。驗證會透過使用者的驗證電子郵件地址來完成。你可以根據工作流程的要求建立任意數量的個人存取權杖，並且應該像對待密碼一樣妥善保管它們。針對不同的應用程式使用不同的權杖是最具安全性的做法。若要在 GitHub 中建立個人存取權杖，您可以流覽至 [設定]，然後在 [開發人員設定] 下方便能找到 [個人存取權杖]。

顯示 GitHub 個人存取權杖範例的螢幕擷取畫面。

您可以將個別權杖限縮於只能授予驗證待指派工作所需的存取權。權杖繫結至特定使用者，並與使用者對組織和存放庫的存取權保持一致。您可以隨時撤銷個人存取權杖，這在發生安全性入侵時格外重要。請務必與您的小組溝通，使他們像對待使用者名稱和密碼一樣妥善保管其個人存取權杖。如果權杖遭到盜用，應立即採取行動，撤銷權杖。

建立個人存取權杖的詳細步驟列於此處：建立個人存取權杖 - GitHub 文件

裝置權杖

裝置權杖基本上就是 PAT 的機器帳戶版本，在設備內容中使用，在非用戶繫結的特定用例中提供對特定存放庫的存取權限。使用 OAuth 流程的應用程式設定會使用裝置權杖。這些權杖通常用於執行器、特殊應用程式服務、Cron 作業 (Linux)，或其他與自動化工作相關的類似案例。就像個人存取權杖一樣，它會繫結至個人帳戶，而您建立裝置權杖的帳戶會取用授權。

GitHub 應用程式安裝權杖

安裝權杖可讓 GitHub 應用程式針對組織中的應用程式安裝提出已驗證的 API 要求。在建立安裝權杖之前，必須在目的地存放庫中安裝權杖將套用權杖的 GitHub 應用程式。安裝權杖的有效期限為 1 小時。由於安裝權杖是出於特定目的而產生，而且在相對較短的時間內便會過期，所以它們很安全。

OAuth 存取權杖

OAuth2 權杖可授權使用者使用在瀏覽器中執行的標準 OAuth 應用程式，以及 CLI 工具等無周邊應用程式。它們可讓您的應用程式利用使用者存取權杖來存取 API。這些權杖可讓您將 GitHub 使用者身分識別連接到第三方應用程式，以便應用程式代表您執行動作。舉例來說，如果您想要使用要求 user:email 範圍的應用程式，應用程式將得到您私人電子郵件地址的唯讀存取權。您可以使用適用於生產應用程式的 Web 應用程式流程来取得這些權杖。因為這些權杖是短期的，而且會在 10 分鐘後過期，因此也很安全。

重新整理權杖

重新整理權杖與 OAuth 權杖相連。授予新的 OAuth 權杖時(透過使用者對伺服器要求)，回應中會包含一個重新整理權杖。當使用者權杖到期時，可以利用回撥要求將重新整理權杖換成新的使用者權杖。每次發出新的 OAuth 權杖時，都會包含重新整理權杖。重新整理權杖的有效期為六個月，可有效提醒您更新 OAuth 權杖。

識別前置詞

如我們在業界所見，權杖前置詞是一種能清楚識別權杖的方法。 GitHub 以三個字母的前置詞來代表每個權杖，從公司簽署者開始，gh，後面則是權杖類型的第一個字母。上述權杖類型的結果為：

GitHub 個人存取權杖為 ghp
GitHub 使用者對伺服器權杖為ghu
GitHub 伺服器對伺服器權杖為ghs
OAuth 存取權杖為gho
重新整理權杖為ghr

此外，這些前置詞在權杖內具有分隔符號 (_) 以提高可讀性。底線不是 Base64 字元，有助於確保權杖不會意外被隨機產生的字串 (如 SHA) 複製。此類前置詞更有助於降低私人掃描 (一種 GitHub 進階安全性功能) 為真率的誤判，進一步提高 GitHub 存放庫的安全性。

權杖速率限制

超過速率限制可能會導致開發時間的損失。讓我們來討論一下 GitHub 應用程式和 OAuth 應用程式的速率限制。藉由瞭解速率限制，您可以成為您小組開發人員的資源，協助最佳化組織對於這些 GitHub 資源的投資。

速率限制以每小時要求數為基礎，有助於控制 GitHub 的流量速率。

安裝在 GitHub 企業帳戶上的 GitHub 應用程式的要求速率限制為每小時 15，000 次要求。
OAuth 應用程式會向個別使用者進行驗證，而且每小時要求數限 5，000 次。

對於 Enterprise 系統管理員，您應該監控應用程式的速率限制，並與開發人員合作調整其指令碼，使其維持在限制內。通常，您不需要在意速率限制問題，除非您的開發人員做了類似編寫在工作流程中要求過多資訊的指令碼的動作。此時開發會突然陷入僵局，而速率限制將成為瓶頸。您可限制每小時要求數，或更改工作流程，使其在要求之間等待一段時間，避免速率限制超額的問題。如果您使用基本驗證或 OAuth 時超過速率限制，您可能可透過快取 API 回應和使用條件式要求來解決該問題。

在管理主控台中，您可為企業中未通過身份驗證的使用者設定自訂速率限制，並建立允許特定使用者利用完整 API 速率限制的豁免清單。

管理主控台設定 API 速率限制的螢幕擷取畫面。

您可以利用如下所示的速率限制 API，隨時檢查目前的速率限制狀態。任何 API 要求的傳回 HTTP 標題都會顯示您目前的速率限制狀態。

curl \
  -H "Accept: application/vnd.github.v3+json" \
  https://api.github.com/rate_limit

範例回應

{
  "resources": {
    "core": {
      "limit": 5000,
      "remaining": 4999,
      "reset": 1372700873,
      "used": 1
    },
    "search": {
      "limit": 30,
      "remaining": 18,
      "reset": 1372697452,
      "used": 12
    },
    "graphql": {
      "limit": 5000,
      "remaining": 4993,
      "reset": 1372700389,
      "used": 7
    },
    "integration_manifest": {
      "limit": 5000,
      "remaining": 4999,
      "reset": 1551806725,
      "used": 1
    },
    "code_scanning_upload": {
      "limit": 500,
      "remaining": 499,
      "reset": 1551806725,
      "used": 1
    }
  },
  "rate": {
    "limit": 5000,
    "remaining": 4999,
    "reset": 1372700873,
    "used": 1
  }
}

如需關於速率限制的詳細資訊，請參閱 GitHub 文件上的速率限制。