Skip to main contentSkip to footer
Search
LY Corporation Tech Blog

支持 LY Corporation 和 LY Corporation Group (LINE Plus, LINE Taiwan and LINE Vietnam) 服務，宣傳技術和開發文化。

This post is also available in the following languages. Japanese, English, Korean

為什麼 ID-JAG 是 AI 代理（AI Agent）安全性的未來

時至 2026 年，AI 的發展典範正穩步從單純的聊天介面轉向以行動為核心的執行模式。我們越來越常見到 AI Agent 代表我們行動，自主運用各種內部服務——無論是查詢資料庫、發送訊息，還是建立工單。

然而，隨著這些 Agent 整合的服務數量不斷增加，背後身份驗證與授權的操作複雜度也往往隨之上升。我們觀察到一個趨勢：傳統架構在這個新環境中面臨越來越大的挑戰——使用者頻繁遭遇授權確認提示，進而產生「同意疲勞」；而資安團隊則必須應對日益嚴峻的「影子 AI」與 Token 蔓延風險。因此，導入 AI 以加速工作流程的組織，有時反而因為這些複雜的權限設定而遭遇營運瓶頸。

大家好，我是 Jeongwoo，LY Corporation 的資安平台工程師，負責開發與維運 Athenz。在這篇文章中，我將探討如何透過 Identity Assertion JSON Web Token Authorization Grant（ID-JAG）從根本上解決這些挑戰。ID-JAG 是目前在 Internet Engineering Task Force（IETF）OAuth 工作小組中備受矚目的下一代標準候選規範。

Identity Assertion JSON Web Token Authorization Grant（ID-JAG）的崛起

ID-JAG 是一項新授權標準的草案，目前主要由 Okta 等公司主導提案。這項技術最初於 2024 年 3 月以個人草案形式發布。經過持續討論與修訂後，於 2025 年 6 月 23 日正式宣布為 Okta 官方背書的下一代標準候選。如今，它已從草案蛻變為業界高度期待的下一代協定，相關推進工作也正在加速進行。

我們也在近期於 AI 生態系中備受矚目的 Model Context Protocol（MCP）企業管理授權文件中看到了這一點——文件中明確提及 ID-JAG，將其作為透過現有企業身份提供者（IdP）建構集中式存取控制的方法。這顯示出業界正朝著打造實際生產環境生態系的方向邁出具體步伐。

本文將從 ID-JAG 的核心概念，到其主要優勢與導入考量，做全面性的介紹。

什麼是 ID-JAG？

簡而言之，ID-JAG 是一項將單一登入（SSO）信任模型延伸至 API 存取領域的規範。

IETF 官方草案對其目的有如下描述：

[ID-JAG] 可用於將多個 SaaS 應用程式的 SSO 關係延伸，進而涵蓋這些應用程式之間的 API 存取。本規範實現了跨越政策或行政邊界的 Authorization Server 之間的聯盟（Federation）。應用程式在 SSO 中所信任的同一企業 IdP，可延伸用來仲介對 API 的存取。

— Appendix A.1. Enterprise Deployment - draft-ietf-oauth-identity-assertion-authz-grant-02

簡而言之，其目標是將透過 SSO 與 IdP 建立的信任關係，應用於應用程式之間，或 Agent 與服務之間的 API 存取。核心理念在於集中治理——明確規範哪個應用程式在什麼情境下，有權存取特定的資源 API。

在技術層面，它結合了兩項現有的 Request for Comments（RFC）規範：

它定義了一套流程：由 IdP 簽發一個可透過密碼學驗證的已簽名 JWT，作為一種「介紹信」。API 資源端信任這封介紹信，並據此簽發最終的 Access Token。

ID-JAG 中的角色

id_jag_characters

為了理解整體運作機制，讓我們依據 ID-JAG 草案第 2.1 節「角色」，定義四個主要角色：

  • Requesting Agent：嘗試呼叫其他應用程式 API 的 AI Agent 或應用程式。

  • Enterprise IdP：提供內部 SSO 並持有集中授權政策的企業身份提供者。

  • Authorization Server：被呼叫之目標應用程式的授權伺服器。

  • Resource Server：實際被呼叫的 API。

釐清各角色定義後，讓我們來看看這四個角色如何協同合作，安全地完成 API 呼叫。

ID-JAG 的基本流程

id_jag_flow

基本流程分為以下五個步驟：

  1. SSO 登入：使用者登入 Requesting Agent，Requesting Agent 從 IdP 取得 ID Token。

  2. Token Exchange 請求：Requesting Agent 將 ID Token 提交給 IdP，請求進行 Token Exchange，並指定 ID-JAG 作為所需的 Token 類型。（RFC 8693）

  3. 政策評估與回應：IdP 評估組織的管理員政策，若審核通過，則將 ID-JAG 回傳給 Requesting Agent。

  4. Access Token 交換：Requesting Agent 將取得的 ID-JAG 提交給 Authorization Server，以換取最終的 Access Token。（RFC 7523）

  5. API 存取：Requesting Agent 使用取得的 Access Token 呼叫 Resource Server。（RFC 6749）

這裡的關鍵在於授權的焦點已發生轉移。授權不再建立於 Requesting Agent 與 Resource Server 之間的個別關係，而是建立於組織管理的 Enterprise IdP 與 Authorization Server 之間的關係之上。更重要的是，最終產出的 ID-JAG 是一個可透過密碼學驗證的 JWT。

組織導入 ID-JAG 的預期效益

不僅僅是協定層面的變革，以下我將說明導入 ID-JAG 可能為實際企業環境與工程組織帶來的潛在影響。

no_more_user_consent

首先，最直觀的效益是使用者體驗的提升。過去，使用者每次連接應用程式時，往往需要透過同意畫面手動授予權限。而 ID-JAG 的概念能將授權流程集中至 IdP 的管理員政策中統一處理。特別是在 AI Agent 的情境下，工具越多通常意味著越多的同意彈窗（進而導致同意疲勞），這種做法預期能大幅緩解此問題。

[Resource Authorization Server] 無需直接向資源擁有者取得使用者同意。

— 4.1. Overview - draft-ietf-oauth-identity-assertion-authz-grant-02

除了使用者體驗之外，整個組織還可以從以下兩個主要面向獲益：

符合稽核需求的可視性

IdP 所簽發的 ID-JAG 明確記載了哪個 Audience 與哪些 Scope 被授予給哪個實體。這意味著只要架構經過 IdP 路由，組織內部複雜的跨服務連線事實便會自然地彙整至 IdP 端。此外，它不僅能讓你知道哪個應用程式持有 Token，更能讓 Token 儲存詳細的情境資訊——代表誰、哪個 Agent 存取了資源，以及存取的範圍為何。

以下是由 Enterprise IdP 所簽發的 ID-JAG 範例，各欄位的說明標註於註解中。

{
  "sub": "sample-human-user", // 持有 scp（Scope）原始權限的主體
  "client_id": "ai-agent", // 代表 sub（Subject）請求存取的 Requesting Agent 資訊
  "aud": "https://authorization.sample.server/v1", // 目標 Authorization Server
  "scp": "api-writers api-readers", // 授予的範圍／權限
  "iss": "https://enterprise.idp.sample.server/v1", // Enterprise IdP 本身
  "exp": 1773839486, // 此 ID-JAG 的到期時間
  "iat": 1773825086, // 此 ID-JAG 的簽發時間
  "jti": "abcabca-7dc6-42ab-b326-27eb23ecfd8b", // 此 ID-JAG 的唯一識別碼
  // ...
}

將這些 ID-JAG 的簽發事件集中記錄於 Enterprise IdP，當資安事件發生時，責任歸屬的判斷將更加容易。更重要的是，這也大幅簡化了提取並佐證各項合規要求所需稽核軌跡資料的流程。

IdP 便可簽發包含人類使用者與 AI Agent 雙方必要情境的 Token，從而實現安全的委派授權，並在各系統間維持清晰的稽核軌跡。

— Cross App Access: Securing AI agent and app-to-app connections - Okta, Inc.

集中控管以降低風險

「影子 AI」問題——即內部使用者私自連接未經核准的 AI 工具來處理公司資料——造成極高的資料外洩風險。在 ID-JAG 框架下，IdP 被定位為攔截並評估這些工具審核申請的關卡。這使得過去難以追蹤的外部 AI 連線嘗試，得以納入標準且可管理的控管流程之中。

隨著 Agent 不斷增加，組織需要對其存取權限有清晰的可視性，並對授權流程擁有精細的控管能力，才能信任 Agent 在不危及資安與合規的前提下正常運作。

— Okta Newsroom（2025 年 6 月 23 日）

Enterprise IdP 針對 Token Exchange 請求執行集中式政策評估，以決定最終授予的 Scope。換言之，它將 AI 或外部應用程式所請求的 Scope，與組織實際允許的 Scope 加以區分。這形成了一道安全防護網，能夠覆寫並依據組織的資安標準治理權限。

若請求中包含 scope，IdP 必須（MUST）依據 RFC 6749 第 3.3 節的規定進行處理，並評估政策以決定授予的 Scope。

— 4.3.2. Processing Rules - draft-ietf-oauth-identity-assertion-authz-grant-02

有了這個基礎，當需要封鎖連線的情況發生時（例如：未經授權的存取、費用超支、違反合規規定），就無需再費心追蹤並逐一管理各個端點。簽發新 Token 的決策權，實際上已集中至 IdP。

此外，資安團隊在導入 AI Agent 時的另一大頭痛問題是 Token 蔓延——即 API 金鑰、Refresh Token 及服務帳號憑證的失控擴散。ID-JAG 規範建議 Resource Server 不應另行簽發 Refresh Token，而是讓用戶端重新提交 ID-JAG 來更新 Access Token。這種架構以基於協定的動態信任，取代了散落在各系統中的長效憑證。

當 Identity Assertion JWT Authorization 依據 [I-D.ietf-oauth-identity-chaining] 第 5.2 節換取 Access Token 時，Resource Authorization Server 不應（SHOULD NOT）回傳 Refresh Token。

— 4.4.3. Refresh Token - draft-ietf-oauth-identity-assertion-authz-grant/

導入 ID-JAG 的注意事項

目前，ID-JAG 仍是 IETF Internet-Draft，尚未成為正式的 RFC 規範。由於其運作細節可能隨未來討論而有所變動，將核心架構與現行規範緊密耦合存在一定風險。

有鑑於此，以下我將針對企業部署及 LLM Agent 使用企業工具的使用情境，說明導入 ID-JAG 時需考量的限制。這些限制分為規範前提條件，以及實作與營運注意事項兩大類。

規範前提條件

若要在實際系統中實作 ID-JAG，必須滿足草案中規定的前提條件：

  • Requesting Agent 必須在 Enterprise IdP 與 Authorization Server 雙方均完成 OAuth 2.0 用戶端（Client）註冊。

  • Enterprise IdP 與 Requesting Agent 之間，以及 Enterprise IdP 與 Authorization Server 之間，必須事先建立明確的信任關係。

  • Enterprise IdP 必須依據企業政策，預先授予 Requesting Agent 存取 Authorization Server 所需的 Scope。

  • 用戶端（Client）已在 IdP Authorization Server 完成 OAuth 2.0 用戶端註冊。
  • 用戶端（Client）已在 Resource Authorization Server 完成 OAuth 2.0 用戶端註冊。
  • 企業已在其 IdP 與用戶端（Client）之間，針對 SSO 及 Identity Assertion JWT Authorization Grant 建立信任關係。
  • 企業已在其 IdP 與 Resource Authorization Server 之間，針對 SSO 及 Identity Assertion JSON Web Token Authorization Grant 建立信任關係。
  • 企業已授予用戶端（Client）代表使用者，以特定 Scope 集合存取 Resource Authorization Server 的權限。

— A.1.1. Preconditions - draft-ietf-oauth-identity-assertion-authz-grant-02

即便使用 ID-JAG，系統間的邏輯責任邊界仍必須維持。為防止非預期的權限提升，Enterprise IdP 不得針對其自身所簽發的 ID-JAG 回應 Access Token。即使在實體或功能上高度整合的環境中，建立這種自我簽發或自我交換的流程，也違反了本規範的資安前提。

特別需要注意的是，Identity Provider 絕對不得（MUST NOT）針對其自身所簽發的 ID-JAG 回應 Access Token。這樣做可能導致授權範圍的非預期擴大。

— 8.3 Cross-Domain Use - draft-ietf-oauth-identity-assertion-authz-grant-02

實作與營運注意事項

基於資安考量，建議使用能安全儲存 Secret 的機密用戶端（Confidential Client）。對於獨立行動應用程式等公開用戶端（Public Client），則建議繼續沿用需要使用者互動同意的傳統授權碼授權流程（Authorization Code Grant）。

[ID-JAG] 應僅（SHOULD）支援機密用戶端（Confidential Client）。公開用戶端（Public Client）應（SHOULD）使用現有的授權碼授權流程（Authorization Code Grant），將使用者重新導向至 Resource Authorization Server，透過 OAuth 2.0 授權請求（Authorization Request）讓使用者以互動方式同意存取委派。

— 8.1 Client Authentication - draft-ietf-oauth-identity-assertion-authz-grant-02

在執行期間，Enterprise IdP 會分析 Subject Token 的資安情境，並可能依據政策要求進行額外的身份驗證。因此，系統設計可能需要加入相應的控制邏輯，以處理錯誤並提示使用者重新驗證。

在初始 Token Exchange 請求中，若 Subject 的 Assertion 所包含的身份驗證情境未符合政策要求，IdP 可能要求 Subject 進行升級驗證（Step-up Authentication）。此時可回傳 insufficient_user_authentication 的 OAuth 錯誤回應，將驗證要求傳達回用戶端，其方式類似於 OAuth 2.0 Step-up Authentication Challenge Protocol [RFC9470]。

— 8.2 Step-up Authentication - draft-ietf-oauth-identity-assertion-authz-grant-02

由於系統分離的特性，營運層面也需要納入考量。ID-JAG 採用 JWT 格式，一旦簽發並在網路上傳播後，便難以從中央即時撤銷。為了實現有效的撤銷機制，可能需要設計控制 Token 有效期限的方案，例如縮短 ID-JAG 的有效期並促使更頻繁地更新。

結語

AI Agent 的普及正為 IT 環境帶來深刻變革，但同時也引入了一項新挑戰：如何安全且有效率地治理這些 Agent 的權限。

身份驗證與授權的典範，正從在每個端點個別管理 Token，轉向透過 IdP 集中控管連線信任。在此背景下，正在 IETF 草案中積極討論的 ID-JAG，是一個極具可行性的方案。

近期，我們的開源授權管理平台 Athenz 也順應這一趨勢，開始正式支援 ID-JAG。當然，Token 有效期管理與前置設定等技術限制仍需納入考量。但透過結合 Athenz 與 ID-JAG，組織得以在確保嚴格服務穩定性的同時，全面擁抱 AI 生態系的廣大擴展性，打造穩固的基礎。LY Corporation 將持續關注全球標準化動向與開源生態系發展，將兼顧開發者體驗與資安的適切基礎設施落地應用。

在我的下一篇文章中，我計劃提供一份實作指南，說明如何使用 Athenz 與開源 IdP 簽發 ID-JAG，以及如何將其實際整合至 AI Agent。敬請期待。

感謝您耐心閱讀這篇長文至最後。

同作者的其他文章