簡化 API 認證與個人訪問令牌 — 更安全的 API 令牌
解釋個人訪問令牌(PAT)如何運作,何時使用它們,如何在你的服務中支持 PAT 功能,以及它們與 API 密鑰、API 令牌、不記名令牌、OAuth 令牌和密碼有何不同。
個人訪問令牌(PATs)是用戶生成的令牌,用於替代 API 調用的密碼。PATs 是為特定用戶設計的,提供安全和受控的資源訪問。
輕鬆的身份驗證。細緻的訪問控制。簡化的工作流程。 這只是開發者和產品團隊在全球範圍內依賴個人訪問令牌來提升生產力的幾個原因,無論是管理 CI/CD 管道、集成 API 還是訪問工具。
對 PAT 的運作方式、好處或何時使用感到好奇?本指南已為你準備好答案。
什麼是個人訪問令牌?
個人訪問令牌是一種臨時的、安全的認證方式,可通過 API 訪問你的個人資源和服務。主要由開發者使用,以使訪問 API 或自動化工作流程等任務變得更簡單、更高效。
將個人訪問令牌視為 API 訪問的 "鑰匙",替代密碼的需求。不同於密碼,PATs 具有特定的權限和到期日期,確保它們僅用於其預定目的,如訪問用戶資料或計費系統,而不是管理控 制。
個人訪問令牌的關鍵特徵:
- 開發者友好:個人訪問令牌比完整的 OAuth 工作流程更易於管理,使它們成為腳本、自動化或 CI/CD 管道的理想選擇。
- 多重令牌:用戶可以生成和管理多個個人訪問令牌,每個令牌都專用於特定服務或目的。
- 用戶特定訪問:與全局 API 密鑰不同,個人訪問令牌與個別用戶帳戶相關聯。這意味著團隊成員可能需要為共享訪問創建單獨的令牌。
- 細粒度權限:透過個人訪問令牌,你可以定義特定範圍,僅允許訪問所需的資源和行動。
- 限時訪問:個人訪問令牌可以配置到期日期,降低曝光風險窗口。
- 簡易撤銷:不像密碼,個人訪問令牌可以被撤銷或重新生成,而不會危害帳戶的主要認證資料。
個人訪問令牌 vs. 不記名令牌 vs. API 令牌
- 個人訪問令牌是一種類型的 API 令牌:個人訪問令牌是一種與用戶帳戶相關聯的用戶級別 API 令牌。它授權代表用戶訪問系統資源。因為 PATs 允許對權限進行精細控制——如限制訪問特定存儲庫或組織——並可包括到期日期以增強安全性,所以它們比傳統的 API 密鑰更安全。
- 個人訪問令牌可用作不記名令牌:不記名令牌是一種授權 API 請求的方法,通常使用 OAuth 或 JWT 等協議動態創建。個人訪問令牌是靜態版本的不記名令牌,由用戶手動生成(例如,在 GitHub 上)。例如,在使用 GitHub PAT 進行 API 調用時,你在請求頭中包含它作為
authorization: bearer <your-pat>
。在這種情況下,PAT 作為不記名令牌。 - API 令牌是一個廣義術語:API 令牌是用於認證 API 請求的任何令牌的通用術語。它包括不同類型,如不記名令牌、OAuth 令牌和個人訪問令牌。PATs 和不記名令牌只是 API 令牌的特定類型。
選擇你的 AuthN 和 AuthZ 機制
在採用個人訪問令牌之前,了解它在更廣泛的認證方法中的角色至關重要。有多種機制可供選擇,了解它們的比較很重要。下面是一個全面的表格,概述 個人訪問令牌(PATs)、密碼、API 鍵 和 OAuth 令牌 之間的主要差異,以幫助你做出明智決策。
- 個人訪問令牌: 一種輕量級的認證方法,適合自動化任務或 API 訪問。提供精確、細粒度的權限控制,確保安全和量身定制的訪問。
- 密碼: 一種傳統的認證方法,用於通過用戶界面訪問個人帳戶。賦予與帳戶用戶相同的權限,沒有額外的細緻控制。
- OAuth 令牌: 為第三方服務授予有限訪問的最安全方法。允許用戶定義特定的訪問範圍,而不暴露他們的憑據,確保安全性和靈活性。
- API 鍵: 通常用於自動化 API 訪問,API 鍵與服務帳戶相關聯,而不是個人帳戶。然而,它們缺乏 PATs 或 OAuth 提供的詳細權限控制。
特徵 | 密碼 | 個人訪問令牌 | OAuth 令牌 | API 鍵 |
---|---|---|---|---|
定義 | 用戶使用身份識別符和密碼進行認證。 | 用於訪問特定資源或 API 的令牌,通常具有有限權限。 | 用戶授予第三方應用訪問其數據而不共享憑據的系統。例如,使用 Google 登錄 | 用戶端用來認證 API 請求的唯一字符串。 |
範圍限制 | 一旦登錄,通常授予對用戶帳戶的完全訪問。 | 允許對權限進行細粒度控制。 | 允許用戶定義第三方應用可以訪問的內容。 | 通常授予對特定 API 資源的訪問。沒有細緻的控制。 |
撤銷 | 不更改密碼難以撤銷,影響多個服務。 | 用戶或管理員可以輕易撤銷。 | 可以在不影響用戶憑據的情況下撤銷。 | 可以在 API 服務端撤銷或再生。 |
到期 | 如果用戶不改變,就不會過期。 | 通常有效期長,但可配置為過期。 | 訪問令牌在設定時間後過期;刷新令牌可以延長訪問時間。 | 通常有效期長,但可以被 API 提供者輪換或限制。 |
易用性 | 容易記住,但處理不當風險高。 | 對於自動化任務來說生成和使用都很簡單。 | 需要初始用戶互動,但提供安全的訪問委派。 | 在請求中使用簡單,但不適合用戶面向的認證。 |
最佳用途 | 客戶端用戶的基本登錄和驗證。 | 自動化、限制 API 資源訪問和 CI/CD 管道中的開發。 | 第三方應用需要有限訪問用戶數據而不存儲密碼。 | 後端服務,服務器到服務器的通信和公共 API。 |
安全風險 | 如果被盜,則授予對帳戶的完全訪問。 | 如果洩露,只獲得指定資源的訪問權。可以輕易撤銷。 | 如果洩露,第三方應用可以在授權範圍內執行操作。 | 如果被盜,通常用於服務器到服務器的訪問。 |
個人訪問令牌如何運作?
個人訪問令牌的運作方式類似於 OAuth 訪問令牌,但通常是沒有用戶可讀內容的字符串。當你使用例如 GitHub 的服務進行身份驗證時,你可以生成一個與你的用戶帳戶綁定的 PAT,並為其分配特定權限。此令牌作為使用密碼進行請求的一個安全替代品,諸如通過 API 訪問私人存儲庫。
通常,PAT 包含在請求頭中,如下例所示:
通過這種方式發送你的 PAT,服務可以驗證你的身份,評估與令牌關聯的權限,並提供所請求的數據或執行指定的行動。
如何使用個人訪問令牌?
- 生成個人訪問令牌:首先,通過你正在使用的平台創建個人訪問令牌並選擇特定範圍以定義其訪問權限(範圍)。
- 驗證 API 請求:準備好你的個人訪問令牌後,使用它來驗證需要安全訪問的服務請求。在 API 請求的授權頭中將令牌作為不記名令牌包含。
- 撤銷個人訪問令牌:如果需要停用令牌,通過平台的認證設置簡單撤銷它。一旦撤銷,使用該令牌進行的任何 API 請求將自動被拒絕。
什麼時候應使用個人訪問令牌?
個人訪問令牌在需要為你的 API 提供安全、開發者友好及有範圍的訪問時表現出色。以下是一些理想的使用案例:
- 自動化任務: 完美適用於需要從 API 提取數據的腳本或工具,無需開發者嵌入敏感憑據。
- 細緻的權限控制: 通過授予腳本或工具有限權限來啟用精確訪問,如訪問特定存儲庫,而不暴露完整帳戶權限。
- 臨時訪問: 適合時間敏感的情境,限制訪問時間可最小化安全風險。
- 簡化的開發者訪問: 為單個開發者提供訪問的一種便捷方式,無需配置完整的 OAuth 授權流的複雜性。
- 第三方集成: 通過限制訪問特定預定義操作來優化與外部工具的功能。例如,當公司使用項目管理工具時,第三方集成可以允許團隊成員直接從 Slack 聊天中創建任務或更新狀態,而不需要對項目管理工具進行全面訪問。
GitHub 自 2013 年以來推動個人訪問令牌的使用,因其簡單和靈活而流行。許多開發者工具和 SaaS 平台支持 PATs,使其易於使用,成為開發者的最愛選擇:
-
GitHub/GitLab/Azure DevOps (開發工具): 有助於自動化 CI/CD,連接到其他工具,以及管理代碼存儲庫。
-
Figma (設計工具): 使得通過 API 集成更容易在設計上合作。
-
Atlassian Jira / Asana (項目管理): 使得通過 API 創建、更新或刪除任務、管理沖刺和組織項目變得容易。
我可以與其他用戶分享個人訪問令牌嗎?
簡單回覆—不,你不應該這麼做。
令牌應該是與個人帳戶相關聯的,絕不應該分享。如果其他人需要訪問,最好生成具有其權限的唯一令牌或設置用戶角色以避免安全風險。 濫用令牌可能導致預期外的訪問、數據被入侵或隱私侵犯。保持令牌私密,並撤銷任何你懷疑被洩露的令牌。
啟用你的應用生成個人訪問令牌與 Logto
無論你是在提供 B2B 服務還是開發尖端的 AI 產品,實施開發者友好的認證和授權都是至關重要的。個人訪問令牌可以為你的業務解開新機會。
Logto,綜合客戶身份及訪問管理(CIAM)解決方案,讓你可以輕鬆創建、管理和撤銷個人訪問令牌。以下是你可以如何開始:
- 瀏覽至 Logto Console > 用戶管理。
- 訪問特定用戶的資料,以管理他們的個人訪問令牌。
使用 Logto,你可以:
- 生成新的個人訪問令牌。
- 為單個用戶管理多個令牌。
- 設置令牌的自定義過期日期。
- 為了更好的組織重命名令牌。
- 在不再需要時撤銷令牌。
此外,你可以通過 Logto 管理 API 使用戶能在其個人資料設置頁面自我管理個人訪問令牌。