為什麼你的產品需要 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 之上的#

從本質上講，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 不支持直接在你的應用中收集密碼。這是有意為之。ROPC 流 不建議用於 OAuth 2.0 安全最佳實踐 的原因很好——它不太安全且難以安全擴展。

Logto 也是一個 OAuth 2.0/OIDC 提供者（身份提供者）#

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

除了為自己的應用提供登錄體驗之外，Logto 還支持 第三方應用集成，讓外部服務可以依賴 Logto 作為它們的身份來源。

實際上這意味著什麼呢？

作為一個 身份提供者 (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. M2M 授權：伺服器到伺服器（客戶端憑證流） 機器（或後端服務）需要在沒有用戶的情況下安全通信。
3. 設備流：智能電視、控制台、物聯網設備： 像電視或打印機這樣的設備需要驗證用戶。設備流是 OIDC 的一部分。
4. 你有整合需求：你不僅在驗證用戶——你在創建一個生態系統，在那裡 外部應用、合作夥伴或代理 可以與你的平台集成並安全訪問用戶數據。

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

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

1. 遠程 MCP 服務器

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

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

   你運營自己的業務服務，比如一個項目管理工具或客戶平台——你想讓其他產品或代理與之集成。這可能意味著提取數據、觸發工作流程，或將你的功能嵌入其他環境。OAuth 2.0/OIDC 允許進行細顆粒度的、基於令牌的訪問控制，而不共享用戶憑證。

3. 構建你自己的代理

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

4. 智能設備的興起

   像 AI 翻譯器或智能會議記錄器這樣的硬件設備，由於 LLM 的加持，變得越來越強大。隨著更低的成本和更高的性能，更多這樣的設備進入市場。這些設備常需要一種方法來驗證用戶並訪問基於雲的服務——特別是在輸入接口有限的情況下。這就是像 OAuth 的 設備授權流程 和基於 OIDC 的身份驗證變得至關重要的地方。

什麼時候你可能不需要 OAuth 2.0/OIDC#

當然，也有可能你目前不需要 OAuth 2.0 或 OIDC 的情況——至少在現在不需要。換句話說，如果你的當前用例很簡單或完全自成一體，這些協議可能不會立即提供價值。

然而，隨著你的產品發展或你的生態系統擴展，從長遠來看，對 OAuth 2.0 和 OIDC 的需求往往會更加明顯。

1. 簡單的內部應用

   如果你的應用僅被公司內部的一個小團隊使用，且不需要與第三方服務整合或公開 API，一個基本的用戶名-密碼身份驗證系統（例如，cookie 會話）可能就足夠了。

2. 不需要用戶身份驗證

   如果你的產品沒有用戶帳戶或身份感知功能——例如，公開內容網站或使用靜態 API 密鑰的服務器到服務器工具——OIDC 就不需要。

3. 不需要委託訪問

   當你需要用戶授權應用訪問他們在另一系統中的數據時，OAuth 就顯得尤為突出（例如，Google Drive）。如果你不整合第三方 API 或構建多服務工作流程，OAuth 會增加複雜性而價值不大。

4. 單環境，風險極小

   對於早期原型、MVP 或內部測試工具，當簡單和速度勝過安全需求時，你可以考慮稍後再實施 OAuth/OIDC。

關於選擇正確身份驗證策略的最終思考#

你可能暫時不需要 OAuth 2.0 或 OIDC —— 這完全可以理解。在早期階段，簡單的解決方案往往能完成任務。但隨著你的產品增長，隨著代理和 AI 更加註入我們的構建方式，隨著你的生態系統向合作夥伴和第三方開放，安全和標準化的身份認證從可有可無的選擇變為必需。

而不是在以後追趕，值得現在就打下基礎。採用 OAuth 2.0 和 OIDC 不僅是為了解決今天的問題——還是為了為即將到來的未來做好準備。