甚麼是個人存取權杖（PAT）？更安全的 API 權杖

解釋個人存取權杖（PATs）如何運作、何時使用、如何在你的服務中支援 API 驗證，以及它們與 API 鍵、API 權杖、持有者權杖、OAuth 權杖和密碼有甚麼不同。

Ran

Product & Design

2/20/2025

Stop wasting weeks on user auth

Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.

Get started

個人存取權杖（PATs）是用戶產生的權杖，用於取代 API 呼叫的密碼。PATs 是為特定用戶而設，能夠提供安全且可控的資源存取。

無憂驗證。細緻存取控制。優化工作流程。 這些只是全球開發者和產品團隊倚賴個人存取權杖提升生產力的其中幾個原因，無論是管理 CI/CD pipeline、整合 API，還是存取各類工具。

想知道 PATs 如何運作、有甚麼好處或何時該用？這份指南會為你解答。

甚麼是個人存取權杖？

個人存取權杖是一種臨時又安全的驗證方式，讓你可以透過 API 存取個人資源和服務。它主要由開發人員用於簡化存取 API 或自動化工作流程的操作，令相關工作又快又高效。

你可以把個人存取權杖想像成 API 存取的「鑰匙」，取代傳統密碼。跟密碼不同，PATs 有明確的權限及到期日，確保它們只用於指定用途，例如存取用戶個人檔案或賬單系統，但不能用作管理員權限等。

個人存取權杖的主要特色：

開發者友好：PATs 比完整的 OAuth 流程更易管理，非常適合作為腳本、自動化或 CI/CD pipeline 的驗證方式。
可建立多個權杖：用戶可以針對不同服務或需求產生及管理多個個人存取權杖。
用戶專屬存取：與全域 API 鍵不同，PATs 綁定到個別用戶帳號。團隊成員若需協作，必須各自建立權杖。
細緻權限管理：PATs 可以設定細分的權限範圍（scope），只授權所需的資源和操作。
時間有限存取：PATs 可設定到期日，如有洩漏，可大幅減少風險期。
簡易撤銷：與密碼不同，PATs 可隨時撤銷或重設，而不會影響帳戶主要密碼。

個人存取權杖 vs 持有者權杖 vs API 權杖

個人存取權杖是 API 權杖的一種：PAT 是綁定用戶帳號的用戶層級 API 權杖，可授權用戶代表自己存取系統資源。PATs 比傳統 API 鍵更安全，因為它們可以細分權限（例如限制某些倉庫或組織的存取），並設有過期日以提升安全性。
個人存取權杖可作為持有者權杖使用：持有者權杖是一種 API 請求的授權方式，通常透過 OAuth 或 JWT 等協議動態產生。個人存取權杖是持有者權杖的靜態版本，由用戶手動產生（例如 GitHub）。例如你用 GitHub PAT 執行 API 請求時，在 request header 輸入 authorization: bearer <你的 pat>，這時 PAT 就作為持有者權杖運作。
API 權杖是總稱：API 權杖泛指用於 API 驗證的各種權杖，包括持有者權杖、OAuth 權杖、個人存取權杖等。PAT 和持有者權杖只是 API 權杖的不同類型。

挑選合適的 AuthN 和 AuthZ 機制

在使用個人存取權杖前，最好先了解 PAT 在整體驗證機制中的角色。市面有多款驗證方法，了解其比較很重要。以下表格總結了 個人存取權杖（PATs）、密碼、API 鍵、和 OAuth 權杖 的關鍵分別，助你選擇最合適方案。

個人存取權杖： 輕量級驗證方式，適用於自動化任務或 API 存取。能夠精確細分權限，實現安全又靈活的控管。
密碼： 傳統驗證模式，用於經使用者介面登入個人帳號。賦予與帳戶持有者相同權限，不具細分性。
OAuth 權杖： 最安全的第三方存取授權方案。用戶可明確指定存取權限，不暴露憑證，兼顧安全與彈性。
API 鍵： 一般用作自動化 API 存取，綁定服務帳號而非個人帳戶。但權限控管不及 PAT 或 OAuth 細緻。

功能	密碼	個人存取權杖	OAuth 權杖	API 鍵
定義	用戶通過帳號及密碼驗證身份。	用於存取指定資源或 API 的權杖，通常有權限限制。	系統讓用戶授權第三方應用存取資料而無需公開憑證，如 Google 登入。	用戶端在 API 請求中使用的獨特字元串。
權限範圍	登入後一般賦予用戶帳號完整存取。	可實現細緻權限控管。	可由用戶指定第三方 app 存取內容。	通常僅授予特定 API 資源存取，無細緻控制。
撤銷方式	撤銷繁瑣，須修改密碼且影響多項服務。	用戶或管理員能輕鬆撤銷。	可撤銷而不影響用戶憑證。	可於 API 服務方撤銷或重設。
有效期	除非用戶主動更改，一般不會過期。	常為長期有效，但可設為過期。	權杖會於指定時間後過期，可用 refresh token 延長存取。	多為長期有效，但服務方可定期輪替或限制。
易用程度	易記但誤用時風險大。	自動化任務易於產生及操作。	首次使用需用戶互動但可安全授權。	請求時易於調用，但不利用作用戶驗證。
最佳應用場景	終端用戶日常登入與驗證。	自動化、受限 API 資源存取、CI/CD pipeline 開發。	第三方應用需有限存取權、並避免儲存密碼。	後端服務、伺服器之間通訊、公共 API。
安全風險	遭竊可獲得帳號所有權限。	洩漏只影響指定資源，且易於撤銷。	洩漏後的動作限於授權範圍。	遭竊多用於伺服器間存取。

個人存取權杖如何運作？

個人存取權杖運作類似 OAuth Access Token，通常是用戶無法直接閱讀內容的字串。當你像 GitHub 這類服務驗證帳號時，可以針對帳號產生 PAT 並設定權限，這個權杖就是用來取代密碼進行如存取私有倉庫等 API 請求。

PAT 一般用在 HTTP request 的 header，如以下例子：

服務會藉此驗證你的身份，檢查權杖的權限，再決定是否提供資料或執行操作。

如何使用個人存取權杖？

產生個人存取權杖：先到相關平台產生權杖，並選擇所需存取權限（scope）。
API 驗證請求：產生好權杖後，用它作為 bearer token 放在 API 請求的 authorization header，驗證存取。
撤銷權杖：如需停用權杖，直接到平台驗證設定撤銷該權杖。被撤銷後，任何 API 請求都自動被拒絕。

甚麼時候適合用個人存取權杖？

個人存取權杖最適合你需要為 API 提供安全、開發者友好且具細緻權限控管的場景。以下為常見用法：

自動化任務： 適合需從 API 擷取資料，而不想讓開發者暴露敏感憑證的自動腳本或工具。
細緻權限控管： 讓程式和工具只獲準特定權限（例如某倉庫），不開放全部帳戶存取。
臨時存取： 驟時有效，減低安全風險。
簡化開發者存取： 無需完整 OAuth 流程，給個別開發者授權存取最方便。
第三方整合： 將第三方工具的功能限制到特定操作，提升 API 整合安全。例如公司結合項目管理工具，第三方工具可讓團隊直接在 Slack 聊天裡建立/更新任務而無需完全開放權限。

自 2013 年起，GitHub 積極推動 PAT 的應用，因其簡單又靈活，獲眾多開發工具及 SaaS 平台支援，成為開發者最愛：