代理型應用程式中的身份驗證和識別變化及不變之處
隨著 AI 代理變得更具能力和連接性，構建安全和可擴展的代理型產品需要在身份驗證和身份識別方面有堅實的基礎。本指南分解了發生的變化、未變的部分，以及每個開發者需要知道的，以便在新背景下導航。
Product & Design
最近我檢視了這篇文章，並提到了代理身份驗證：
我們看到一些暗示這可能的樣子。最新的 MCP 規範，例如，包含了一個基於 OAuth 2.1 的授權 框架，暗示可能朝著給 AI 代理提供範圍限定、可撤回的令牌，而不是原始秘鑰。我們可以想像一個場景，其中 AI 代理不會獲得你實際的 AWS 密鑰，而是獲得一個短期憑證或允許其執行定義狹窄動作的能力令牌。
https://a16z.com/nine-emerging-developer-patterns-for-the-ai-era/
很多朋友和不在安全或 CIAM 領域的人印象中，這是新東西，但這絕對不是。OAuth 是一個標準的基於令牌的授權協議，包含具有範圍權限的令牌（訪問令牌）。這些是時間敏感和範圍有限的，從而確保對資源和服務的安全性和適當的訪問控制。在全球 SaaS 市場（人工智能之前），大多數專業身份解決方案已經建立在這之上。
當你將 Google 帳戶連接到第三方應用程式，如 Notion 或 Zoom 時，它使用 OAuth 只請求必要的權限，比如訪問你的日曆或聯絡人，而無需暴露你的 Google 密碼。你可以隨時從你的 Google 帳戶設置中撤銷該訪問權限。這種委託訪問模式正是 OAuth 的設計目的，而這也是今天被擴展到代理型應用的相同基礎。
在代理世界中不變的部分
身份驗證不是新事物，仍然基於 OAuth 2.1
- MCP 著重於 LLM 與你應用工具和背景的互動。
- A2A 著重於實現代理間的任務交換。
但當涉及到身份驗證和授權時，兩者仍依賴於行業中 已確立的標準，如 OAuth。
MCP 授權伺服器必須實現 OAuth 2.1，並為機密和公開客戶端採取適當的安全措施。
A2A 客戶端負責通過 A2A 協議本身之外的過程獲取必要的憑證材料（例如，OAuth 2.0 令牌、API 密鑰、JWTs）。這可能涉及 OAuth 流程（授權碼、客戶端憑證）、安全密鑰分發等。
正如 Google 所說：
與其為安全和運營創建新的專有標準，A2A 旨在與現有企業基礎設施和廣泛採用的最佳實踐無縫融合。
是否需要給代理創建一個唯一身份?
很多炒作和 FOMO 內容推動了這樣的理念：隨著代理變得更普遍，我們需要一個系統來管理代理身份。
答案是：是和不是。
是，因為我們在用戶和機器之間引入了新層次。這確實需要：
- 管理和識別代理
- 分配唯一 ID
- 跟蹤日誌
- 審計行動（知道任務是否由人類或代理執行）
然而，在大多數技術情況下，沒有必要創建一個正式的“代理身份”的概念。
代理 ≠ 用戶，≠ 服務帳戶。
在每個代理後面，都仍然有一個用戶，通常用戶身份就夠了。
今天，大多數代理：
- 基於用戶授權行動（例如，OAuth 令牌）
- 執行邏輯或進行 API 調用
- 執行短期、一性任務（不需要跟蹤）
在這個意義上，代理只是一個工具功能，不需要一個全球唯一的 ID。
例如：
- 一個 GPT 代 理調用你的日曆 API 只需要你授予的訪問權限。
- 一個 LangChain 代理不需要身份，只要它能調用正確的工具就行了。
即使在人工智能出現之前，我們已經有機器對機器 (M2M) 身份驗證的概念。
M2M 意味著服務間的自動化數據交換，無需人類干預。
在這種情況下，身份驗證通常使用客戶端應用或服務帳戶。
如果你真的希望你的代理擁有一個身份（例如用於審計等），你可以使用應用 ID 就足夠了。
你仍然需要定義你的產品架構
這一點沒有改變。無論你的產品是否涉及代理，其身份系統的架構取決於你的用戶是誰以及你的系統如何與他們互動。
如果你正在構建一個面向消費者的代理型產品： 你將需要輕量級的登入方法（電子郵件、電話、社交登入），以及一個統一的用戶池來管理與你的應用及其代理互動的人。代理代表這些用戶使用委託的令牌（例如，通過 OAuth）。
範例：
想像你正在構建一個 AI 日程安排助理，或一個 AI 驅動的日曆 bot。
每個用戶使用他們的個人 Google 帳戶登入。你的系統使用 OAuth 獲得訪問他們日曆的權限。代理本身沒有身份，它使用用戶的令牌來安排會議、檢查可用性或發送提醒。身份架構簡單：一個全球用戶池，令牌存儲，每位用戶的同意追蹤。
如果你正在構建一個 B2B 代理型平台：
你將需支持在組織層級而非單個用戶的身份支持。這包括：
- 企業客戶的單一登入（SSO）
- 工作區或租戶層級的分隔
- 組織層面的代理委託政策（例如，控制代理可以在各團隊之間做什麼）
- 在公司層面為所有代理的活動提供管理層次的可見性和日誌
範例：
想像你正在構建一個平台，為公司提供 AI 代理來自動化內部工作流程，如一個安全分析 bot，監控日誌和發送提醒，或一個銷售助理，從 CRM 數據中撰寫電子郵件。
使用你的平台的公司希望：
- 使用現有單一登入（SSO）系統登入
- 控制代理能訪問什麼（例如，內部工具、文檔系統）
- 查看每個代理在何種授權下由哪個員工執行了何種任務
在這種情況下，你的身份架構需要支持多租戶設計、範圍的代理權限，以及根據業務租戶制定的組織特定策略。代理仍然代表用戶行動，但許可和身份界限則依每個企業租戶來執行。
在這兩種情況下，身份模型定義了代理如何運作、可以訪問的內容，以及系統怎樣確保責任性。
使用這份指南來幫助你規劃你的身份和產品架構。
https://docs.logto.io/introduction/plan-your-architecture/b2c
https://docs.logto.io/introduction/plan-your-architecture/b2b
你仍然需要安全層來保護你的代理動力應用
無論是否是代理應用，這些基礎安全層對於保護你的用戶和系統是必要的：
-
即使憑證遭到泄露，也能防止未經授權的訪問。
範例：如果一個代理幫助你執行高度風險的操作，例如進行交易或更改身份設置，應該保持人力循環，並在確認操作前使用 MFA。
-
阻止自動化濫用，如憑證釣取或機器人推動的註冊。
範例：在 3 次登入失敗後顯示 CAPTCHA，以防止暴力破解攻擊。
-
確保用戶及代理僅能訪問其有權訪問的內容。
範例：公司工作空間的 AI 助理可以閱讀日曆事件，但不能訪問賬單數據，除非顯式指派了更高角色。
-
改善用戶體驗並減少弱密碼風險。
範例：讓用戶使用發送到其電子郵件的魔術鏈接登入，或使用面容 ID 的生物識別提示。
這些功能適用於傳統和代理驅動應用，尤其當代理開始在敏感數據和系統間運作時。
代理世界中發生了什麼變化
身份驗證比以往更重要
隨著代理和多代理工作流的出現，我們看到用戶、代理、API 和 MCP 服務器都相互作用的新用例。這些場景的數量和種類正在迅速增長，遠遠超過過去。
每當這些連接發生時，授權就顯得異常重要。用戶必須明確表示同意，許可必須在系統間謹慎管理。因此，每個人現在都在談論保持一個“人力循環”，確保用戶對代理能做什麼有充分的控制和可見性，以及代理被獲授什麼範圍的權限。
你的 AI 應用可能需要與許多外部服務集成
MCP 生態系統正在擴大，這意味著你的應用不再只是獨立的服務：它是更大、連接的網絡的一部分。
為了向 LLM 提供豐富、有用的上下文，你的代理可能需要：
-
訪問多個 MCP 服務器
範例：想像一個 AI 專案經理從 Jira 獲取任務更新，從 Google Calendar 獲取團隊可用性，還從 Salesforce 獲取銷售數據，而每一個都可能由不同的 MCP 服務器驅動。為了生成一個每週摘要，代理必須安全地與多個數據源互動。在這裡，身份驗證和授權進來了，以保護每次連接並控制數據的共享方式。
-
連接到外部 API 和工具
範例：一個客戶服務代理可能需要從 Shopify 獲取訂單歷史、在 Zendesk 中更新票據，並在 Slack 中觸發工作流。如果沒有集成，代理將被孤立且無效。
隨著代理承擔更多責任，集成成為實用的關鍵。你的 AI 產品不僅僅是它自身能做什麼，還關於它能在連接的生態系統中訪問、協調和推理什麼。這就是為什麼為可互操作性進行安全和靈活構建比以往更重要。
你需要擁抱開放標準：OAuth／OIDC 比以往更重要
在 AI 時代，對安全、靈活集成的需求正在增長。這使得 OAuth 2.0 和 OIDC 比以往更重要。
關鍵用例包括：
- 遙控 MCP 服務器：讓第三方代理使用委託令牌安全地訪問你的產品。
- 第三方集成：允許其他工具或代理連接到你的應用（例如，一個項目管理平台），而無需原始憑證。
- 代理開發：構建能在服務間代表用戶安全行動的 AI 代理。
- 智能設備：使用 OAuth／OIDC 進行身份驗證用戶和連接到雲端 — 尤其在最低 UI 情況下。
這些協議提供安全的、以令牌為基礎的、用戶同意的訪問。
在代理型、連接系統的世界中，這至關重要。檢查這篇文章，看看 OAuth 和 OIDC 為什麼重要
在代理型軟體時代設計信任與擴展性
隨著代理型產品的發展，身份和授權的核心原則保持不變，但背景正在轉變。代理引入了新的委託、同意和訪問表面。因此，堅持像 OAuth 這樣的開放標準、構建明確的架構、和加強穩固的安全措施不僅僅是最佳實踐，而是基礎。細心的設計意味著你的系統將能秉承信任、靈活性和在 AI 驅動的未來中擴展。