Cross-App Access (ID-JAG) for AI Agents, and Where Keycloak Stands

Last updated: May 2026

Cross-App Access, formalized in the IETF as the Identity Assertion JWT Authorization Grant (ID-JAG), is an emerging standard that lets a trusted identity provider broker API access between applications instead of forcing each app to run its own OAuth consent dance. For AI agents that act on a user’s behalf across many SaaS tools, it replaces a sprawl of per-app authorizations and long-lived refresh tokens with a single, auditable identity-to-access exchange that each resource owner still controls.

The problem: agents that traverse many apps

A modern enterprise agent rarely lives inside one application. Ask it to “summarize this week’s deals and post the recap to the team channel,” and it may need to read a CRM, query a data warehouse, pull documents from storage, and write to a messaging tool. Each of those is a separate API with its own authorization model.

The classic way to grant that access does not scale to agents:

• Per-app consent prompts. Every app the agent touches wants the user to click through an OAuth consent screen. One task can fan out into a dozen redirects, and the user has no clear picture of what they just approved.
• Long-lived refresh tokens everywhere. To avoid re-prompting, integrations hoard refresh tokens. Now there is a pile of durable, broadly scoped credentials sitting in agent infrastructure, each a standing breach risk and a key-rotation headache.
• No central revocation or audit. When access is granted app-by-app, there is no single place to see what the agent can reach, or to cut it off in one move when something goes wrong.

For a security team, that is the worst of both worlds: more credentials, less visibility. Cross-App Access exists to collapse that mess back into something the identity provider can govern.

What ID-JAG / Cross-App Access actually is

ID-JAG is a profile of the JWT authorization grant. In plain terms: the identity provider you already trust for single sign-on becomes the broker that lets one application get scoped access to another, without re-authenticating the user against each app.

There are three parties:

1. The identity provider (IdP) authenticates the user and can issue identity assertions about them.
2. The requesting application (the agent, or the app hosting it) needs to call another app’s API on the user’s behalf.
3. The resource application owns the protected API and still decides what, if anything, to grant.

The flow, simplified:

User ──auth──▶ Identity Provider
                     │  issues an identity assertion for the user
                     ▼
Requesting app ──exchanges assertion──▶ Identity Provider
                     │  returns an ID-JAG (a scoped, short-lived grant)
                     ▼
Requesting app ──presents ID-JAG──▶ Resource app's token endpoint
                     │  resource app validates the grant
                     ▼
            Resource app issues an access token

Two properties make this a good fit for agents. First, the grant is short-lived and scoped to a specific resource, so there is no fleet of durable refresh tokens to steal. Second, the resource application keeps its own authorization control: presenting a valid ID-JAG is a request, not a guarantee, and the resource server applies its own policy before issuing a token. The IdP brokers identity; each app still owns its access decisions.

This is not a vendor side project. The draft is moving through the IETF OAuth working group as draft-ietf-oauth-identity-assertion-authz-grant, with public momentum from identity vendors including Okta and WorkOS (WorkOS open-sourced its auth.md materials around it). The Model Context Protocol (MCP) specification, the connective tissue for tool-using agents, has adopted Cross-App Access concepts, which is why this matters now rather than someday.

Where Keycloak stands today

Keycloak is tracking the standard from both ends, but the two ends are at very different stages. There are really two roles in an ID-JAG world:

• Consumption (the relying side): accepting a JWT-based grant and exchanging it for an access token. This builds on RFC 7523, the JWT Authorization Grant.
• Issuance (the broker side): Keycloak acting as the identity provider that mints identity assertions and ID-JAGs for the requesting app.

Here is the honest status as of the current 26.6.2 release (2026-05-19):

What that means in practice:

• You can experiment with the consumption half now. Since 26.5, the JWT Authorization Grant landed as a preview feature, so Keycloak can sit on the relying side of a JWT-grant exchange. Preview means evaluate it, do not bet production on it: behavior and configuration can still change before it stabilizes.
• You cannot yet have Keycloak be the broker. The piece that turns Keycloak into the identity provider issuing ID-JAGs is still a proposal. It is tracked as issue keycloak/keycloak#43971 and milestoned for 26.7.0, the next minor release. Until it ships, Keycloak is a participant in the flow, not the assertion issuer at its center.

If you are designing an agent platform today, the practical read is: prototype against the consumption preview, keep your integration boundaries clean, and plan for the issuance side to arrive in a coming release rather than building around its absence permanently.

What this means for you

The direction of travel is clear. As agents move from demos to production, “let the agent collect a refresh token for every app” stops being acceptable to security teams, and a brokered, short-lived, centrally governed model takes over. Cross-App Access is the shape that model is converging on, and the open-standards ecosystem, IETF plus MCP, is lining up behind it.

The risk for teams running their own identity stack is falling behind the curve: adopting too early on shifting preview APIs, or too late and rebuilding integrations under pressure. Tracking a fast-moving standard like ID-JAG across preview, milestone, and stable releases is exactly the kind of work that quietly eats engineering time.

That is where managed Keycloak helps. Skycloak runs Keycloak for you and stays current with the upstream standards story, so when issuance lands in a future minor and the consumption feature graduates out of preview, your deployment is ready instead of stranded on an old release. You get the open standard, on the open-source server, without owning the upgrade treadmill.

If you are starting to map out agent access for your apps, that is a good moment to talk to us.

FAQ

What is ID-JAG?
ID-JAG (Identity Assertion JWT Authorization Grant) is an IETF draft that defines how an application can present an identity assertion from a trusted identity provider, exchange it for a short-lived grant, and use that grant to obtain a scoped access token for another application’s API. It is the standard underpinning Cross-App Access.

How is Cross-App Access different from regular OAuth?
Regular OAuth typically requires the user to consent to each application individually, and apps often store long-lived refresh tokens to avoid re-prompting. Cross-App Access lets the identity provider broker access between apps using a short-lived, scoped grant, so there is less per-app friction and far less standing credential to protect, while each resource app keeps its own authorization decision.

Does Keycloak support Cross-App Access right now?
Partly. As of release 26.6.2, Keycloak supports the consumption side, the RFC 7523 JWT Authorization Grant, as a preview feature introduced in 26.5. The issuance side, where Keycloak itself issues identity assertions and ID-JAGs, is still a proposal (issue keycloak/keycloak#43971) milestoned for 26.7.0.

Why do AI agents need this?
Agents commonly act across many SaaS applications in a single task. Without a brokered model, each app demands its own consent and stashes its own long-lived token, which multiplies credentials and destroys central visibility and revocation. Cross-App Access gives the identity provider one place to govern what an agent can reach on a user’s behalf.