為什麼你的產品需要 OAuth 2.0 和 OIDC —— 尤其是在 AI 時代

從一開始，Logto 就建立在對開放標準的堅定信念之上。我們選擇遵循 OIDC、OAuth 2.0 和 SAML 等協議——不僅因為它們被廣泛使用，還因為它們代表了業界可信賴的成熟安全做法。安全一直是我們的優先事項。我們也始終忠實於開源精神，並遵循 客戶身份管理 和現代身份驗證的最佳實踐。

但我們也在過程中學到了一些東西：

對於每個人來說，OAuth 2.0 和 OIDC 都不是輕而易舉的。對於不熟悉這些協議的開發者來說，這些概念可能會顯得陌生，有時甚至會感到難以理解。這給我們帶來了真正的挑戰，因為我們需要在不妥協安全性的情況下簡化開發者的體驗。

有兩點特別明顯：

1. 即使我們非常努力地使集成盡可能順暢，理解 ID 令牌、訪問令牌以及它們如何工作的基本概念仍然存在學習曲線。
2. 我們經常被問的一個問題是：「我可以跳過登錄頁面的重定向嗎？」不幸的是，重定向是 OIDC 工作原理的一部分，是安全驗證所必需的。

來自我們 Discord 用戶的常見問題（為了隱私已遮擋他們的 ID 和頭像）。

每個決策都有取捨——但有時一些早期的選擇在新用例出現時會特別有價值。現在我們正進入一個新的時代：AI 時代。

在本文中，我將探討何時你的產品應該使用 OIDC 和 OAuth 2.0，何時可能不需要它們，以及為什麼我一直提倡從一開始就採用這些開放標準——尤其是當你在建立真正的業務並選擇 CIAM 解決方案時。我還將解釋為什麼 AI 的崛起使這一決策變得比以往任何時候都更重要。

OAuth 2.0 真正做了什麼（用一個簡單的比喻）#

對於不太熟悉 OAuth 2.0 的讀者，讓我花點時間再次簡要介紹一些基本概念——以便更清楚地理解。

OAuth 2.0 是用於委派授權：OAuth 2.0 是一個業界標準的授權協議——它允許一個服務在另一個服務的資源所有者同意的情況下代表其訪問資源。

在 OAuth 場景中，使用者（資源所有者）允許客戶端應用程式在不共享密碼的情況下對 API 或資源服務器進行有限的訪問（範圍權限）。OAuth 定義了如何請求和發放客戶端可以用來調用受保護 API 的訪問令牌。與要求你的憑證來訪問另一個服務的早期應用相比（這是一個嚴重的安全風險），這是一個革命性的變革。使用 OAuth 2.0，使用者批准特定訪問，客戶端獲得一個令牌，其中僅包含所需的權限和持續時間——不交换密碼，大大提高了安全性。

想像 OAuth 2.0 就像入住酒店。

你（使用者）是房間的主人（你的數據）。但不是將自己的房間鑰匙（你的密碼）交給某人，而是去前台請求一張臨時訪問卡（訪問令牌），只允許你的訪客或朋友進入健身房或游泳池——而不是整個房間。

酒店工作人員（OAuth 系統）發放這張有限的卡片，並附有具體規則：

• 只能用於健身房（特定資源）。
• 有效期較短。
• 不會讓任何人進入你的房間。

這樣一來，你不必交出你的主鑰匙——系統即使有人拿到了那張有限卡片仍然保持安全。

讓我們再看一個例子。OAuth 2.0 在社交登錄情況中被廣泛使用。

假設你正在註冊新應用如 Notion，而不是創建新的用戶名和密碼，你點擊 「用 Google 繼續」

在 OAuth 2.0 背後，以下是發生的事情：

1. 你被重定向到 Google 的登錄頁面，在那裡登錄（如果還未登錄）。

2. Google 問：

   「你允許此應用查看你的基本資料和電子郵件地址嗎？」

3. 你點擊「允許」，然後 Google 發送給應用一個訪問令牌。

4. 應用使用該 令牌 ：

   • 確認你的 身份 （通過你的電子郵件和資料信息）。
   • 創建或登錄一個賬戶——從未看過你的 Google 密碼。

OIDC 真正做了什麼（用一個簡單的比喻）#

現在讓我們來看看 OIDC —— 一個更新和更先進的標準。OpenID Connect 旨在進行身份和驗證：它是在 OAuth 2.0 之上構建的一個 驗證 層。雖然 OAuth 2.0 本身不告訴應用程序使用者是誰（它只涉及訪問令牌和範圍），OIDC 添加了一個標準方式來處理用戶登錄和身份。

當使用 OIDC 時，授權伺服器還充當 OpenID 提供者（一個身份提供者），其驗證用戶並發放包含有關用戶信息的 ID 令牌 （即「身份聲明」）。

簡而言之，OAuth 2.0 回答 「這個客戶端可以訪問這個資源嗎？」 而 OIDC 回答 「這個剛剛登錄的用戶是誰？」。它們讓你的應用程序可以驗證用戶身份，然後使用授權令牌代表用戶訪問 API。

讓我們再用酒店比喻來更好地理解 OAuth 2.0 與 OIDC。

想像你正在入住酒店。

• OAuth 2.0 就像讓酒店允許你的 朋友 代表你使用健身房和游泳池。

  你去前台，給予許可，酒店給你的朋友一個 訪客通行證。

  酒店並不在乎 朋友 是誰——只在乎他們被允許使用設施。

  👉 這就是 OAuth： 「這個應用程序可以訪問我一些數據或服務。」

• OIDC 就像要求酒店在允許訪問之前確認 這個人是誰。

  所以你的朋友還展示了一個 身份證 —— 現在酒店知道他們的名字、身份和他們是經核實的訪客。

  👉 這就是 OIDC： 「這就是這個用戶，他們已經登錄。」

Logto 如何使用 OAuth 2.0 和 OpenID Connect (OIDC)#

Logto 的核心身份驗證功能是基於 OIDC (OpenID Connect) 構建的#

在其核心，Logto 是一個 OpenID Connect (OIDC) 提供者——這是一個基於 OAuth 2.0 的標準，專注於安全的、現代的用戶身份驗證。Logto 是一個專業的 CIAM 解決方案，我們管理的核心構建模塊就是身份。

我們以安全性作為基石來設計 Logto。這意味著默認強制執行 PKCE，阻止不安全的流如 隱式流，並依賴於 重定向 來安全地處理登錄。

為什麼重定向？#

OIDC 是為瀏覽器驗證而設計的。這不僅僅是一個技術選擇——而是關於為用戶提供跨平台的安全、一致的體驗。將用戶重定向到身份提供者（如 Logto、Google 或 Microsoft）能夠實現這一目標。

這是 典型流程 看起來的樣子：

1. 用戶點擊「登錄」

   → 你的應用將他們發送到 Logto 的登錄頁面。

2. 他們安全登錄

   → 這就是 MFA、生物識別或社交登錄發生的地方。

3. Logto 將他們送回

   → 並附上安全重定向的令牌或授權碼。

4. 你的應用完成登錄

   → 驗證該令牌，用戶被登錄成功。

這種模式看似簡單，但卻帶來了強大的好處：

• 你的應用不直接處理憑據——這意味著風險更小。
• 更容易添加如 MFA 等功能，不需更改應用程式代碼。
• 也適用於移動應用：
  • iOS 使用 ASWebAuthenticationSession
  • Android 使用 Custom Tabs

如果你的產品橫跨多個應用，重定向允許 單點登入 —— 使用者只需登入一次，便能在應用間無縫流動。

Logto 不支援在你的應用中直接收集密碼。這是故意的。由於 OAuth 2.0 的安全最佳實踐，ROPC 流不被推薦——因為其安全性較低且更難安全地擴展。

Logto 也是一個 OAuth 2.0/OIDC 提供者（Identity Provider）#

Logto 不僅僅是一個身份驗證服務器——它是一個完整的 OAuth 2.0、OpenID Connect (OIDC) 和身份提供者 (IdP)。這意味著它可以安全地管理用戶身份並發放其他應用程序可以信任的令牌。

除了為你自己的應用提供登錄體驗，Logto 也支持 第三方應用集成，讓外部服務可將 Logto 作為其身份來源。

這在實踐中意味著什麼？

作為一個 Identity Provider (IdP)，Logto 負責用戶驗證，管理憑據，並發放身份驗證令牌。一旦用戶登入，Logto 可以讓他們訪問不同的應用——即使是其他廠商的應用——而不需要再次登錄。這與「用 Google 登錄」或「用 Microsoft 登錄」基於相同的概念。

在這個上下文中有兩種應用：

• 第一方應用：你建立並完全控制的應用，直接與 Logto 集成。
• 第三方應用：外部服務由合作夥伴或貴組織以外的開發者構建。

Logto 使你的用戶可以使用他們現有的 Logto 賬戶登錄這些第三方應用——就像企業用戶使用他們的 Google Workspace 憑據來登入工具如 Slack 一樣。這使你能夠：

• 在你的生態系統中提供 單點登入 (SSO)。
• 構建一個 開放平台，允許第三方開發者在其應用中添加「用 Logto 登錄」。

你什麼時候真正需要 OAuth 2.0 和 OIDC？#

1. 如果你之前使用 Auth0（或類似）： Auth0 已經是一個 OAuth 2.0 和 OIDC 提供者。它管理用戶登錄、令牌發放，並與你的 API 或應用集成。
2. 機器對機器的授權：伺服器對伺服器（客戶端憑證流） 機器（或後端服務）需要在沒有用戶的情況下安全通信。
3. **設備流：智能電視、遊戲機、物聯網設備：**像電視或打印機這樣的設備需要驗證用戶。設備流是 OIDC 的一部分。
4. 你有互動需求：你不僅僅是驗證用戶——你還在創建一個生態系統，以便 外部應用、合作夥伴或代理 可以與你的平台集成並安全地訪問用戶數據。

為什麼在 AI 時代 OAuth 和 OIDC 比以往更重要#

在 AI 時代，我們看到新的集成和訪問需求激增——尤其是在自動化代理、智能設備和系統間通信的領域。這些趨勢使得 OAuth 2.0 和 OIDC 比以往任何時候都更加重要。以下是一些例子：

1. 遠程 MCP 伺服器

   你構建了一個遠程 MCP（模型上下文協議）伺服器，並希望第三方代理連接到它。這些代理需要安全的訪問來請求上下文、執行操作並交換數據——而不危及用戶信任。OAuth 提供了安全委託訪問的機制。

2. 開放你的產品進行集成

   你運行自己的商務服務 —— 比如項目管理工具或客戶平台 —— 並希望允許其他產品或代理與之集成。這可能涉及提取數據、觸發工作流程或將你的功能嵌入其他環境。OAuth 2.0/OIDC 可實現基於令牌的細粒度訪問控制而不共享用戶憑據。

3. 構建你自己的代理

   你正在創建一個 AI 代理或助手，希望它能與其他應用和 MCP 伺服器交互——安排會議、發送電子郵件、發布更新或查詢數據。這些需要與第三方服務進行安全的身份驗證和訪問。OAuth 2.0 是你的代理如何獲得授權來代為用戶行動的方式。

4. 智能設備的興起

   硬件設備如 AI 翻譯器或智能會議紀要記錄器正因 LLMs 而變得更強大。隨著成本降低和性能提高，市場上有越來越多這樣的設備。這些設備通常需要一種方式來驗證用戶並訪問基於雲的服務——尤其是在輸入界面有限的情況下。這就是像 OAuth 的 設備授權流程 和基於 OIDC 的身份驗證變得至關重要的地方。

什麼情況下你可能不需要 OAuth 2.0/OIDC#

當然，在某些情況下，你可能不需要 OAuth 2.0 或 OIDC——至少不在當下。換句話說，如果你的當前用例很簡單或完全自包含，這些協議可能不會帶來立即的價值。

然而，隨著你的產品增長或生態系統擴大，長期來看通常需要 OAuth 2.0 和 OIDC。

1. 簡單的內部應用

   如果你的應用僅由公司內的小團隊使用，不需要與第三方服務集成或公開 API，那麼一個基本的用戶名-密碼身份驗證系統（如 Cookie 會話）可能就足夠。

2. 不需要用戶驗證

   如果你的產品沒有用戶帳戶或身份識別功能——如公共內容網站或具有靜態 API 密鑰的伺服器對伺服器工具——則不需要 OIDC。

3. 不需要委派訪問

   當你需要用戶授權你的應用程式訪問他們在另一個系統中的數據（例如 Google Drive）時，OAuth 發揮重要作用。如果你沒有與第三方 API 集成或構建多服務工作流，OAuth 增加了複雜性但價值不大。

4. 單一環境，最低風險

   對於早期階段的原型、MVP 或內部測試工具，在安全性需求不高時，簡化和速度超過安全性優勢，可能會推遲到遲些時候實現 OAuth/OIDC。

有關選擇正確身份驗證策略的最後想法#

你可能不需要立即 OAuth 2.0 或 OIDC —— 這完全沒問題。在早期階段，簡單的解決方案通常能夠完成任務。但隨著你的產品增長，代理和 AI 更多地整合到我們的構建中，並且隨著你的生態系統對合作夥伴和第三方開放，安全的和標準化的身份驗證從不是必需變為必須。

與其以後追趕，不如現在打好基礎。採用 OAuth 2.0 和 OIDC 不僅僅是為了解決當前問題——也是為了為即將到來的變化做好準備。