As of 2026, the AI paradigm is steadily shifting from mere chat interfaces to action-centric execution. We are increasingly seeing cases where AI agents act on our behalf, autonomously utilizing various internal services—whether it's querying databases, sending messages, or creating tickets.
However, as these agents integrate with a growing number of services, the operational complexity of authentication and authorization behind the scenes tends to increase alongside them. We are observing a trend where traditional architectures face growing challenges in this new environment: users are frequently confronted with approval prompts that can lead to consent fatigue, while security teams must navigate the rising risks of "shadow AI" and token sprawl. Consequently, organizations adopting AI to accelerate workflows can sometimes encounter operational bottlenecks due to these complex permission configurations.
Hello, I'm Jeongwoo, a security platform engineer at LY Corporation developing and operating Athenz. In this article, I will explore how we can fundamentally address these challenges using the Identity Assertion JSON Web Token Authorization Grant (ID-JAG), a next-generation standard candidate currently gaining traction within the Internet Engineering Task Force (IETF) OAuth working group.
The emergence of Identity Assertion JSON Web Token Authorization Grant (ID-JAG)
ID-JAG is a draft for a new authorization standard currently proposed primarily by companies like Okta. This technology was first published as an individual draft in March 2024. After ongoing discussions and refinements, it was announced on June 23, 2025, as a next-generation standard candidate officially backed by Okta. As a result, it is transforming from a draft into a highly anticipated next-generation protocol within the industry, and related initiatives are accelerating.
We are also seeing this in the enterprise authorization draft document for the Model Context Protocol (MCP)—which has recently drawn significant attention in the AI ecosystem—where ID-JAG is explicitly mentioned as a method for structuring centralized access control via existing enterprise identity providers (IdPs). This indicates tangible movement toward building an ecosystem for real-world production.
In this article, I will detail everything from the core concepts of ID-JAG to its key benefits and implementation considerations.
What is ID-JAG?
To put it simply, ID-JAG is a specification that extends the trust model of single sign-on (SSO) into the realm of API access.
The official IETF draft describes its purpose as follows:
[ID-JAG] can be used to extend the SSO relationship of multiple SaaS applications to include API access between these applications as well. This specification enables federation for Authorization Servers across policy or administrative boundaries. The same enterprise IdP that is trusted by applications for SSO can be extended to broker access to APIs.
— Appendix A.1. Enterprise Deployment - draft-ietf-oauth-identity-assertion-authz-grant-02
In short, it aims to apply the trust established with an IdP through SSO to API access between applications, or between an agent and a service. The goal is to enforce centralized governance over which application is authorized to access specific resource APIs, and under what context.
Technically, it combines two existing Request for Comments (RFC) specifications:
It defines a flow where the IdP issues a cryptographically verifiable signed JWT as a sort of "letter of introduction." The API resource side then trusts this letter and issues the final access token.
The roles in ID-JAG
To understand the overall operational mechanism, let's define the four main roles based on Section 2.1. Roles in the ID-JAG draft:
-
Requesting Agent: the AI agent or application attempting to call another application's API.
-
Enterprise IdP: the corporate IdP that provides internal SSO and holds central authorization policies.
-
Authorization Server: the authorization server of the target application being called.
-
Resource Server: the actual API being called.
Now that the roles are clear, let us look at the specific flow of how these four entities collaborate to securely call APIs.
The basic flow of ID-JAG
The basic flow proceeds in the following five steps:
-
SSO login: the user logs into the requesting agent, and the requesting agent obtains an ID token from the IdP.
-
Token exchange request: the requesting agent presents the ID token to the IdP, requests a token exchange, and specifies ID-JAG as the requested token type. (RFC 8693)
-
Policy evaluation and response: the IdP evaluates the organization's administrator policies and, if approved, returns the ID-JAG to the requesting agent.
-
Access token exchange: the requesting agent presents the issued ID-JAG to the authorization server to obtain the final access token. (RFC 7523)
-
API access: the requesting agent uses the issued access token to call the resource server. (RFC 6749)
The distinctive point here is that the focal point of authorization has shifted. It is no longer based on individual relationships between the requesting agent and the resource server, but rather on the relationship between the organization-managed enterprise IdP and the authorization server. Crucially, the resulting ID-JAG is a cryptographically verifiable JWT.
Expected benefits for organizations adopting ID-JAG
Moving beyond just a protocol change, I have outlined the potential impacts ID-JAG implementation could have on actual corporate environments and engineering organizations.
First, the most apparent benefit is improved user experience. Previously, users often had to manually grant permissions via a consent screen every time they connected an app. With the concept of ID-JAG, though, the authorization process can be centralized into the IdP's administrator policies. Particularly in the context of AI agents, where more tools typically mean more consent pop-ups (leading to consent fatigue), this approach is expected to alleviate the issue significantly.
[The resource authorization server] does not need [to] obtain user consent directly from the resource owner.
— 4.1. Overview - draft-ietf-oauth-identity-assertion-authz-grant-02
Beyond user experience, organizations as a whole can expect benefits from two main perspectives:
Audit-ready visibility
The ID-JAG issued by the IdP explicitly handles which audience and scope were granted to which entity. This means that as long as the architecture routes through the IdP, facts regarding complex inter-service connections within the organization naturally aggregate on the IdP side. It also goes beyond simply knowing which app holds a token; it allows the token to store context detailing on whose behalf, which agent accessed the resource, and to what extent.
Below is a sample of an ID-JAG issued by an enterprise IdP. The meaning of each field is noted in the comments.
{
"sub": "sample-human-user", // The principal who holds the original permissions for the scp (Scope)
"client_id": "ai-agent", // Information of the Requesting Agent asking for access on behalf of the sub (Subject)
"aud": "https://authorization.sample.server/v1", // The target Authorization Server
"scp": "api-writers api-readers", // The range/permissions granted
"iss": "https://enterprise.idp.sample.server/v1", // The Enterprise IdP itself
"exp": 1773839486, // Expiration time of this ID-JAG
"iat": 1773825086, // Issued at time of this ID-JAG
"jti": "abcabca-7dc6-42ab-b326-27eb23ecfd8b", // Unique ID for this ID-JAG
// ...
}With these ID-JAG issuance events centralized at the enterprise IdP, it becomes much easier to determine responsibility when a security incident occurs. Importantly, it also simplifies the process of extracting and proving audit trail data required for various compliance requirements.
The IdP can then issue tokens that contain the necessary context about both the human user and the AI agent, facilitating secure delegation and maintaining a clear audit trail across systems.
— Cross App Access: Securing AI agent and app-to-app connections - Okta, Inc.
Centralized control to mitigate risks
The issue of "shadow AI"—where internal users connect unapproved AI tools to handle company data—creates a high risk for data leaks. Under the ID-JAG framework, the IdP is positioned to intercept and evaluate approval for these tools. This brings previously opaque external AI connection attempts under standard, manageable control processes.
As agents proliferate, organizations need clear visibility into their access rights and granular control of the authorization process to be able to trust that agents will operate without compromising security and compliance.
The enterprise IdP executes a centralized policy evaluation in response to a token exchange request to determine the final granted scopes. In other words, it separates the scopes requested by the AI or external app from the scopes the organization actually permits. This creates a safety net to overwrite and govern permissions in alignment with the organization's security standards.
If scope is present, the IdP MUST process it according to Section 3.3 of RFC 6749 and evaluate policy to determine the granted scopes.
— 4.3.2. Processing Rules - draft-ietf-oauth-identity-assertion-authz-grant-02
Because of this foundation, when situations arise where connections must be blocked (for example, unauthorized access, cost overruns, compliance violations), it eliminates the hassle of tracking down and managing individual endpoints. The decision-making power for issuing new tokens is effectively centralized at the IdP.
Additionally, a major headache for security teams when adopting AI agents is token sprawl—the uncontrolled proliferation of API keys, refresh tokens, and service account credentials. The ID-JAG specification recommends that resource servers do not issue separate refresh tokens. Instead, clients should re-submit an ID-JAG to refresh their access token. This architecture replaces long-lived credentials scattered across systems with protocol-based, dynamic trust.
The Resource Authorization Server SHOULD NOT return a Refresh Token when an Identity Assertion JWT Authorization is exchanged for an Access Token per Section 5.2 of [I-D.ietf-oauth-identity-chaining].
— 4.4.3. Refresh Token - draft-ietf-oauth-identity-assertion-authz-grant/
Considerations when adopting ID-JAG
At present, ID-JAG is still an IETF Internet-Draft and not a finalized RFC specification. Because its operational mechanics may change through future discussions, tightly coupling core architectures to the current specification carries inherent risk.
With that in mind, I will outline the constraints to consider when adopting ID-JAG, focusing on the use case of enterprise deployment and LLM agents using enterprise tools. These are divided into specification preconditions and implementation or operational considerations.
Specification preconditions
To implement ID-JAG in an actual system, the preconditions specified in the draft must be addressed:
-
The requesting agent must be registered as an OAuth 2.0 client with both the enterprise IdP and the authorization server.
-
Explicit trust relationships must be established in advance between the enterprise IdP and the requesting agent, as well as between the enterprise IdP and the authorization server.
-
Based on corporate policy, the enterprise IdP must pre-grant the requesting agent the scope required to access the authorization server.
- The client has a registered OAuth 2.0 client with the IdP Authorization Server.
- The client has a registered OAuth 2.0 client with the Resource Authorization Server.
- Enterprise has established a trust relationship between their IdP and the Client for SSO and Identity Assertion JWT Authorization Grant.
- Enterprise has established a trust relationship between their IdP and the Resource Authorization Server for SSO and Identity Assertion JSON Web Token Authorization Grant.
- Enterprise has granted the Client permission to act on behalf of users for the Resource Authorization Server with a set of scopes.
— A.1.1. Preconditions - draft-ietf-oauth-identity-assertion-authz-grant-02
Even when using ID-JAG, logical boundaries of responsibility between systems must be maintained. To prevent unintended escalation of privileges, the enterprise IdP must not issue access tokens in response to an ID-JAG that it issued itself. Even in physically or productively integrated environments, setting up such a self-issuance or self-exchange flow violates the security premises of this specification.
In particular, the Identity Provider MUST NOT issue access tokens in response to an ID-JAG it issued itself. Doing so could lead to unintentional broadening of the scope of authorization.
— 8.3 Cross-Domain Use - draft-ietf-oauth-identity-assertion-authz-grant-02
Implementation and operational considerations
For security reasons, the use of confidential clients—which can safely store secrets—is recommended. For public clients like standalone mobile apps, it is recommended to continue using the traditional authorization code grant, which involves interactive user consent.
[ID-JAG] SHOULD only be supported for confidential clients. Public clients SHOULD use the existing authorization code grant and redirect the user to the Resource Authorization Server with an OAuth 2.0 Authorization Request where the user can interactively consent to the access delegation.
— 8.1 Client Authentication - draft-ietf-oauth-identity-assertion-authz-grant-02
During runtime, the enterprise IdP analyzes the security context of the subject token and may demand additional authentication based on policies. As a result, system design may need to incorporate control logic to handle errors and prompt the user for re-authentication.
In the initial token exchange request, the IdP may require step-up authentication for the subject if the authentication context in the subject's assertion does not meet policy requirements. An insufficient_user_authentication OAuth error response may be returned to convey the authentication requirements back to the client similar to OAuth 2.0 Step-up Authentication Challenge Protocol [RFC9470].
— 8.2 Step-up Authentication - draft-ietf-oauth-identity-assertion-authz-grant-02
Operational considerations also come into play due to the nature of system separation. Because an ID-JAG is formatted as a JWT, it is difficult to instantly invalidate a token centrally once it has been issued and propagated across the network. To achieve effective revocation, it may be necessary to implement designs that dictate token lifetimes, such as keeping the ID-JAG validity period short and encouraging frequent renewals.
Conclusion
The adoption of AI agents is bringing significant changes to IT environments, but it has simultaneously introduced the new challenge of how to govern these agents' permissions securely and efficiently.
The paradigm of authentication and authorization is shifting away from managing tokens individually at every endpoint, moving toward centrally controlling connection trust via the IdP. In this context, ID-JAG, which is actively being discussed as an IETF draft, proves to be a highly viable option.
Recently, our open-source authorization management platform, Athenz, has also begun to officially support ID-JAG in alignment with this trend. Naturally, there are technical constraints to consider, such as token lifetime management and preliminary configurations. But by leveraging Athenz with ID-JAG, organizations can build a robust foundation that fully embraces the vast scalability of the AI ecosystem while maintaining strict service stability. At LY Corporation, we will continue to monitor global standardization trends and open-source ecosystems, applying appropriate infrastructure to the field that balances both developer experience and security.
In my next blog post, I plan to deliver a hands-on guide on how to issue an ID-JAG using Athenz and an open-source IdP, and how to actually integrate it with an AI agent. Please look forward to it.
Thank you for taking the time to read this long post to the end.
