北京
周三下午，一個工程師正在調(diào)試他的AI代理。這個代理需要調(diào)用三個下游服務(wù)：一個數(shù)據(jù)庫、一個云函數(shù)和一個內(nèi)部API。他下意識地把用戶的IdP令牌隨著請求一路傳了下去——反正能通過認(rèn)證就行，對吧？
這樣做當(dāng)然能跑通。用戶登錄后拿到一個令牌，代理持有它，再讓每個下游服務(wù)也能識別“用戶是誰”。表面上看，身份傳遞沒有斷，審計日志里也能追到同一個sub字段。對于急著上線的團隊來說，“能跑就行”的誘惑始終存在。
但安全工程師看到的是另一幅圖景。那個令牌本來就是發(fā)給瀏覽器前端的，受眾寫的是網(wǎng)關(guān)，不是后面那些服務(wù)。它包含的權(quán)限可能是幾十個微服務(wù)的全部訪問范圍，有效期還是按小時計的。更要命的是，一旦這個令牌落入代理進程的內(nèi)存，代理就等于拿到了用戶的萬能鑰匙——它可以冒充用戶去任何地方。Christian Posta在AgentGateway的博客里說得直接：“把敏感的MCP/API憑證（密鑰、API key、令牌等）暴露給AI代理，就是一張你不該制造的泄漏面。”
于是，一個選擇擺在了架構(gòu)師面前：是繼續(xù)依賴原生用戶令牌的“直接透明”，還是引入一套令牌交換機制，把每一次下游調(diào)用都重新包裝一次身份？
接受令牌交換，意味著每次代理代表用戶訪問下游時，網(wǎng)關(guān)要先拿用戶的IdP令牌向授權(quán)服務(wù)器換一個新的、專用的令牌。新令牌的受眾被限制為那個特定的下游服務(wù)，作用域只包含這次調(diào)用的最小權(quán)限，有效時間可能只有幾分鐘。用戶身份（sub聲明）還保留著，但令牌已經(jīng)不可能被濫用于其他服務(wù)。如果代理本身也要被識別，還會帶上act聲明，標(biāo)明誰在代表用戶行事。整個流程符合RFC 8693的標(biāo)準(zhǔn)化定義，不再需要每個服務(wù)各自理解用戶原始令牌的龐大聲明集。
反對的聲音往往落在復(fù)雜度和延遲上：多一次令牌交換就多一次網(wǎng)絡(luò)往返，而且還要配置交換策略、維護令牌映射。但在AgentGateway的實現(xiàn)里，內(nèi)置的后端認(rèn)證策略backendAuth.oauthTokenExchange已經(jīng)封裝了這個過程：網(wǎng)關(guān)收到用戶請求時，自動向Keycloak等身份提供方發(fā)起RFC 8693交換，然后把換來的令牌轉(zhuǎn)發(fā)給上游，原始的令牌根本不會走出網(wǎng)關(guān)。所有交換還配置了緩存，重復(fù)調(diào)用不會一直捶打IdP。
所以這場辯論的結(jié)論其實很清楚：當(dāng)AI代理開始觸碰多個下游服務(wù)時，“直接傳原始令牌”就已經(jīng)不是一個架構(gòu)選項，而是一個遲早要爆炸的隱患。用網(wǎng)關(guān)集中進行令牌交換，既保住了用戶的身份信息，又把每個服務(wù)得到的憑證限制在了最小必要范圍內(nèi)。而這一切，靠AgentGateway里一段聲明式的策略配置就能跑通——一個干凈的分離，遠比事后追查“令牌泄漏面”要劃算得多。
特別聲明：以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺“網(wǎng)易號”用戶上傳并發(fā)布，本平臺僅提供信息存儲服務(wù)。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
