識別支援的存取權杖

8 分鐘

在這裡，您將瞭解不同的 GitHub 存取令牌、其應用程式、限制和速率限制。

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

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

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

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

個人存取權杖

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

包含 GitHub 個人存取令牌範例的螢幕快照。

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

如需建立個人存取令牌的詳細步驟，請參閱這裡：建立個人存取令牌 - GitHub Docs

裝置權杖

装置令牌基本上是機器帳戶版本的 PAT，使用於特定裝置的情景中，可存取特定使用案例中非依賴於用戶的資源庫。使用 OAuth 流程的應用程式設定會使用裝置權杖。它們通常用於執行器、特殊應用程式服務、Cron 作業（在 Linux 中），或與自動化工作相關的其他類似案例。就像個人存取令牌一樣，裝置令牌會系結至個別帳戶，而您建立裝置令牌的帳戶會取用授權。

GitHub 應用程式安裝權杖

安裝權杖可讓 GitHub 應用程式針對組織中的應用程式安裝提出已驗證的 API 要求。建立安裝令牌之前，您必須先在目的地存放庫中安裝令牌套用至的 GitHub 應用程式。安裝令牌的有效期限為一小時，而且很安全，因為它們是針對特定用途產生的，而且會在相對短時間內到期。

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 Docs 上的速率限制。

意見反應

此頁面對您有幫助嗎？