繁體中文（台灣）
  • auth
  • cli
  • ai

什麼是 CLI 驗證以及現今常見的方法

CLI 驗證已成為現代開發者工作流程的核心。Logto 支援所有主流的 CLI 驗證方法。

Guamian
Guamian
Product & Design

不要在使用者認證上浪費數週時間
使用 Logto 更快地發布安全應用程式。幾分鐘內整合使用者認證，專注於您的核心產品。
立即開始
Product screenshot

現代開發者工作流程高度依賴命令列工具。從部署雲端服務到執行 AI 代理人或管理基礎設施，CLI 已成為工程師最強大的介面之一。但每一次部署、驗證或執行指令背後，都有一個關鍵需求：

CLI 必須知道你是誰。

這就是 CLI 驗證 的用途。

在本文中，我們將說明 CLI 驗證的意義、其重要性，以及當前開發者生態圈常見的驗證方法。

什麼是 CLI 驗證？

CLI 驗證（命令列介面驗證） 是指 CLI 驗證執行指令的個人或服務身分的機制。

它讓 CLI 能夠：

  • 驗證使用者
  • 取得短效與長效的存取權杖
  • 安全地存取後端 API
  • 維持持續登入狀態

如果瀏覽器依賴 cookie 與 session，CLI 則依賴 本地儲存的權杖，搭配 OAuth 或其他標準化驗證流程。

簡言之，CLI 驗證讓終端機擁有自己的登入系統，讓其可以安全地代表使用者行動。

為什麼需要 CLI 驗證

CLI 驗證解決了多項現實問題：

  1. 身分識別 — API 後端需要知道誰在下達指令。
  2. 安全性 — 開發者不該在終端機或腳本中貼上明文金鑰。
  3. 權杖生命週期 — CLI 需要短效存取權杖，且可自動刷新。
  4. 用戶便利性 — 驗證一次後，開發者不需反覆登入。
  5. 支援自動化 — CI/CD 流程需要機器友好的權杖。

隨著 CLI 功能提升，特別是 AI 工具的流行，對穩健且安全的驗證需求更加重要。

常見的 CLI 驗證方法

不同平台根據安全性、用戶體驗需求及基礎架構設計，採用不同的 CLI 驗證方式。以下是現代開發工具最常用的幾種方法。

1. OAuth 2.0 裝置驗證碼流程（最常見）

這是產業標準流程，常見於：

  • GitHub CLI
  • AWS SSO
  • Azure CLI
  • Vercel CLI
  • OpenAI CLI
  • 許多 AI 原生執行環境

運作方式

  1. CLI 呼叫身分提供者，請求裝置驗證碼。
  2. 使用者被要求造訪一個網址並輸入短驗證碼。
  3. 瀏覽器處理登入流程（密碼、通行密鑰、單一登入）。
  4. 通過驗證後，CLI 取得權杖（存取＋刷新）。
  5. CLI 將權杖本地儲存，未來指令會使用。

為什麼它受歡迎

  • 到處都適用（本機、SSH、容器）。
  • 高安全性。
  • 無需在終端機輸入密碼。
  • 支援 MFA、通行密鑰與企業 SSO。

裝置驗證碼流程成為現代開發工具的 預設，因其在安全性、彈性與使用體驗間取得平衡。

2. Localhost 重新導向 OAuth 流程

友善登入體驗的工具喜歡使用這種方式。

運作方式

  1. CLI 在本地隨機埠啟動極小的伺服器。
  2. 瀏覽器自動打開。
  3. 登入後，身分提供者導回 http://localhost:xxxx/callback。
  4. CLI 取得 OAuth 權杖並關閉本地伺服器。

優點

  • 用戶體驗極佳。
  • 無需複製貼上步驟。

缺點

  • 不適用於遠端 shell 或雲端環境。
  • 需有綁定本地埠口的權限。

常見於偏向 GUI 的 CLI 或追求「一鍵登入」的開發工具。

3. API 金鑰 / 個人存取權杖（舊但仍常見）

部分 CLI 允許開發者貼上 API 金鑰或個人權杖。

範例

優點

  • 簡單。
  • 易於自動化。

缺點

  • 安全性較低。
  • 無 MFA。
  • 不易輪換。
  • 權杖常有過廣的權限。

現代平台多漸漸捨棄此模式，或僅限 機器使用。

4. 用戶端憑證（OAuth2 用戶端憑證流程）

這是服務與 CI/CD 任務無需用戶互動時的 標準 驗證方式。

驗證提供者發給：

  • client_id
  • client_secret

服務會交換這兩者取得存取權杖：

特點

  • 不需用戶參與
  • 無需瀏覽器
  • 權杖短效
  • 適合後端對後端、CI 系統
  • 可與 OAuth2、RBAC 無縫整合

這是所有身份提供者中最廣泛支援的自動化驗證方式。

5. 帳號＋密碼輸入（現已罕見）

直接在 CLI 輸入帳號密碼：

這種方式已過時且不建議使用，原因包括：

  • 密碼輸入易外洩
  • 無 MFA 支援
  • 無法整合 SSO
  • 不利稽核

現代工具幾乎不會用，僅極少數離線或舊式企業環境才出現。

CLI 如何儲存權杖

多數 CLI 將權杖儲存在：

優先考慮

  • macOS 金鑰圈
  • Windows 憑證管理員
  • Linux 金鑰環

後備方案

  • ~/.config/toolname 目錄下加密檔案
  • JSON 或 TOML 格式的設定檔

權杖必須：

  • 保持短效
  • 可自動刷新
  • 可撤銷
  • 限定角色與權限

設計良好的權杖生命週期是 CLI 驗證安全的基石。

你應該選哪種方法？

如果你要設計自己的 CLI：

場景最佳驗證方法
本機用戶登入裝置驗證碼流程
有 GUI 需求的用戶Localhost OAuth 重新導向
CI/CD用戶端憑證流程
快速原型API 金鑰
企業需 SSO裝置驗證碼流程

裝置驗證碼流程是現代預設，因其每個環境都可用且可繼承瀏覽器的安全性。

總結

CLI 驗證是現代命令列工具背後的身分基礎。

它讓開發者可以安全驗證身分、取得權杖，並與雲端服務或 AI 環境互動，而不需暴露敏感憑證。

最常見的 CLI 驗證方式包括：

  1. OAuth 裝置驗證碼流程
  2. Localhost OAuth 重新導向流程
  3. API 金鑰 / 個人存取權杖
  4. 用戶端憑證流程（供 CI/CD 用）
  5. 舊式帳號密碼（現已罕見）

隨著開發工具朝向 AI 化，愈來愈多工作進入終端機，CLI 驗證已成現代身分基礎設施的核心。Logto 支援所有主流 CLI 驗證模式，裝置驗證碼流程目前正在開發中。

👉 立即開始使用 Logto

免費試用 Logto Cloud