ID-JAG, a next-generation standard candidate for solving authentication challenges in the AI era

ID-JAG extends enterprise SSO trust to API access between AI agents, applications, and services. It uses an enterprise IdP to centrally evaluate permissions and issue a signed JWT that can be exchanged for a resource-specific access token. This can reduce consent prompts, improve auditing, and limit token sprawl, but organizations should adopt it cautiously while the specification remains an Internet-Draft.

The Authentication Challenge in the AI Era

• AI agents increasingly perform real work, including:
  • Searching systems
  • Querying databases
  • Sending messages
  • Creating tickets
• As the number of connected services grows, authentication and authorization become more complex.
• Poorly coordinated integrations can turn AI from a productivity tool into an operational bottleneck.
• ID-JAG is being discussed by the IETF OAuth Working Group as a potential solution.

What ID-JAG Is

• ID-JAG, or Identity Assertion JWT Authorization Grant, extends the enterprise IdP’s SSO trust relationship to API access.
• The IdP centrally determines:
  • Which application or agent may access an API
  • Which user or identity it acts for
  • Which scopes or permissions are allowed
• It combines:
  • OAuth 2.0 Token Exchange (RFC 8693)
  • JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523)
• The IdP issues a cryptographically verifiable JWT as an “introduction” or authorization assertion.
• The target authorization server validates that assertion and issues the final access token.

The ID-JAG Participants and Flow

The model involves four main parties:

• Requesting Agent: An AI agent or application calling another service’s API
• Enterprise IdP: Provides SSO and enforces centralized organizational policies
• Authorization Server: Issues tokens for the target application
• Resource Server: Hosts the API being accessed

The basic five-step flow is:

1. The user signs in to the requesting agent, which obtains an ID token from the IdP.
2. The agent presents the ID token to the IdP and requests an ID-JAG through token exchange.
3. The IdP evaluates organizational policy and issues the ID-JAG if access is allowed.
4. The agent presents the ID-JAG to the target authorization server and receives an access token.
5. The agent uses the access token to call the resource server.

The key architectural shift is that authorization decisions move from isolated agent-to-service relationships toward a centrally governed relationship between the enterprise IdP and target authorization servers.

Benefits for User Experience and Auditing

• Centralized IdP policies can reduce repeated consent screens.
• This is especially useful when AI agents connect to many tools and services.
• ID-JAG claims can record important context, such as:
  • The user whose authority is being delegated (sub)
  • The requesting agent (client_id)
  • The target authorization server (aud)
  • Approved scopes (scp)
  • Issuer, issue time, expiration, and unique token ID
• Centralized issuance logs provide a clearer view of service-to-service relationships.
• Security teams can more easily determine which agent accessed which service, on whose behalf, and with what permissions.
• The same records can support incident investigation, compliance audits, and accountability.

Centralized Control and Reduced Token Sprawl

• The IdP can help detect and control unauthorized “shadow AI” integrations.
• It can evaluate every token exchange using consistent organizational policies.
• Requested scopes can be narrowed or overridden according to enterprise security requirements.
• Blocking future access can be handled centrally instead of by changing policies across every endpoint.
• ID-JAG may reduce token sprawl by avoiding additional long-lived refresh tokens.
• The draft recommends that resource authorization servers generally not issue refresh tokens when an ID-JAG is exchanged.
• Agents can instead submit a new ID-JAG to obtain another access token, replacing scattered API keys, service credentials, and refresh tokens with dynamic, policy-based trust.

Adoption Requirements and Risks

• ID-JAG is still an IETF Internet-Draft, not a finalized RFC.
• Its behavior may change, so systems should avoid tightly coupling their core architecture to the current draft.
• Before implementation, organizations need to verify that:
  • The requesting agent is registered as an OAuth client with both the enterprise IdP and the target authorization server.
  • Explicit trust relationships exist between the IdP and agent, and between the IdP and authorization server.
  • The IdP has pre-authorized the agent to act on users’ behalf for the relevant services and scopes.
• Deployment also requires coordinated support from agents, enterprise IdPs, authorization servers, and resource servers.

Organizations should treat ID-JAG as a promising architectural direction for governing AI-agent access, while isolating its implementation behind adaptable interfaces until the standard stabilizes. Pilot deployments should focus on centralized policy enforcement, detailed audit logging, strict scope control, and minimizing long-lived credentials.