ID-JAG, the Identity Assertion JWT Authorization Grant, is a draft OAuth specification for carrying identity assertions across OAuth authorization server boundaries without requiring interactive authorization at each hop. A user authenticates once. The client typically exchanges the resulting identity assertion via RFC 8693 token exchange into an ID-JAG. The ID-JAG is then presented to a target authorization server using RFC 7523 as the authorization grant, producing an access token for that service without a redirect, a consent screen, or a second login.
This same general pattern is also often discussed under the name XAA, for Cross-App Access. In this post I use ID-JAG for the protocol term and XAA only as a shorthand label readers may already recognize.
I am one of the authors of the specification, so I want to be open about where I am describing the current draft and where I am stretching into a broader architectural argument. That distinction matters here because the draft itself is already moving: the newer editor’s copy adds a product and CIAM-shaped example, Customer Identity for Developers. By CIAM here I mean customer identity and access management platforms such as Auth0, WorkOS, Stytch, Descope, and similar product-identity layers. That does not settle the boundary by itself, but it is a helpful sign that the older “Enterprise IdP” framing is already being tested against a wider set of deployment realities.
The argument in this post is narrower than “ID-JAG solves cross-domain authorization.” It is simply that “Enterprise IdP” is too narrow a frame for the trust pattern. In the current draft, the issuer that matters is the IdP the downstream authorization server already trusts for SSO and subject resolution. The broader point is that this immediate-IdP role may be held by a workforce IdP, a CIAM platform, or an internal platform IdP depending on the deployment.
That framing matters now because product ecosystems and agentic systems are increasingly separating workforce authentication, product-local identity, and downstream authorization into different layers. The older habit of treating the top-level workforce IdP as the only IdP that matters no longer fits how many systems are actually built.
What ID-JAG Changes
In the common user-delegated OAuth pattern, the client sends the user to the authorization server for an authorization request, the user authenticates and approves the request there, and the authorization server issues a code or other grant under its own policy. In the ID-JAG draft, the downstream authorization server for this hop is the Resource Authorization Server (RAS). I use “receiving authorization server” here as shorthand for that downstream RAS role.
ID-JAG makes a narrower move. It lets a receiving authorization server accept an identity assertion issued by the IdP the RAS already trusts for SSO and subject resolution as the OAuth authorization grant, instead of forcing the client to run another direct interactive authorization flow there. The IdP becomes the assertion issuer the receiving authorization server relies on for this hop. The receiving authorization server still decides whether to honor the assertion, what scopes to allow, and what token to mint.
That matters because it avoids implying a fundamental OAuth role change. ID-JAG does not redefine the underlying ownership model of the protected resource. In some deployments the effective resource owner is an individual user; in others it is a tenant- or organization-administered account model. The receiving authorization server still issues tokens under its own policy, and the resource server still enforces access to protected resources. What changes is the grant path: the receiving authorization server is willing to treat a trusted IdP-issued identity assertion as sufficient input for token issuance.
When that works well, some approval and policy work can be centralized at the IdP or its surrounding governance layer, but the downstream service does not surrender final control. The IdP mediates the cross-domain hop. The receiving authorization server still applies local policy.
What does change is where user consent and authorization visibility live. In interactive OAuth, the user sees a consent screen at each service. ID-JAG removes that interaction. The governance equivalent is pre-authorized scopes defined at the IdP or in the receiving AS’s client registration, or admin consent granted at the organizational level. The user’s visibility into which downstream services their identity assertion can reach is a policy question each deployment has to answer explicitly, through IdP-level scope governance, admin consent flows, or session-bound scope limits, rather than through interactive consent at each service boundary.
That is an operational consequence worth saying plainly. If a deployment adopts ID-JAG, it is also choosing to move visibility and approval away from the downstream service’s consent screen and into some combination of IdP policy, client registration, tenant admin approval, or other governance controls. If those controls are weak or opaque, the user may lose visibility even if the protocol mechanics are sound.
That is also why ID-JAG should not be read as creating a new concentration of power at the IdP. From a threat-model perspective, an IdP that is already trusted for SSO can often already approximate a similar downstream access outcome indirectly: silently sign the user in, drive the front-channel steps of an OAuth request without the user present, and orchestrate the browser interactions needed for the client to obtain a code through equivalent choreography. In other words, an SSO-trusted IdP may already be able to simulate the consent path without the receiving AS changing its protocol behavior. That is not desirable, and it is not protocol-equivalent to ID-JAG. But it is why the underlying trust question is already there. ID-JAG does not create that trust position. It makes the cross-domain grant path explicit, typed, and reviewable instead of relying on brittle front-channel mechanics to approximate a similar outcome operationally.
The Constraint Is the Trust Relationship, Not “Enterprise”
ID-JAG reads very naturally as an Enterprise IdP story. An Enterprise IdP authenticates employees. Enterprise-managed services trust that IdP and often pre-authorize certain clients and scopes. So ID-JAG lets employees move across those services without extra login prompts. That use case is real, familiar, and valuable.
But the constraint is not just “enterprise.” The constraint is the issuer, client, and policy trust relationship.
The mechanism works because the receiving authorization server has established trust with the issuer for identity assertions and has policy for the client and requested access. In the enterprise examples in the draft, that includes more than generic SSO trust: the client and receiving authorization server are configured for this pattern, and the client has permission to act for the target service with defined scopes. That is the deployment shape the current draft directly specifies.
What “configured for this pattern” means in practice: the receiving authorization server has already established how it recognizes and validates assertions from the issuer the RAS trusts for SSO and subject resolution, and maps that issuer to permitted clients and scopes. In OpenID Connect deployments that usually means issuer metadata and JWKS configuration; in SAML deployments it means the equivalent federation metadata and key trust. ID-JAG adds the grant-type and claim-processing rules on top of that existing trust relationship.
That incremental adoption path was one of the primary goals of ID-JAG. The deployment work is issuer registration, client-to-grant-type binding, and scope policy. It is not new trust infrastructure from scratch. The Resource Authorization Server does not need a new access-token format or a new token-issuance model; it is still issuing its own access tokens under its own policy. The Resource Server does not need to change which authorization server it trusts or what token claims it relies on at runtime. The main change is at the grant-acquisition boundary: which upstream issuer the Resource Authorization Server is willing to accept as input for token issuance.
From an implementation perspective, a resource authorization server can trust more than one issuer. There is no protocol constraint that says one tenant or deployment context must map to exactly one IdP. The cost is complexity: once multiple issuers are accepted, the deployment has to handle issuer routing, account linking, subject normalization, and policy mapping carefully. The constraint is operational clarity, not single-issuer exclusivity.
The broader architectural point is a little different. The protocol does not inherently require the issuer to be the top-level workforce IdP. It requires the issuer to be the IdP the downstream authorization server already trusts for SSO and subject resolution. In some environments, that will still be the enterprise workforce IdP. In others, a CIAM platform or internal platform IdP may federate upstream to the workforce IdP for employee login, but still be the IdP that downstream systems trust directly. In that shape, the chained workforce IdP is upstream authentication infrastructure, while the CIAM or platform IdP is the issuer that actually satisfies the ID-JAG trust condition for those downstream services.
That is exactly why the specification is grounded in identity assertions rather than arbitrary JWT claim sets. The issuer has a defined identity role relative to the receiving authorization server.
The word “enterprise” describes one deployment context where that relationship is common. It does not define the limits of the pattern.
Four Deployment Contexts
Enterprise Workforce
This is the canonical case. The Enterprise IdP is authoritative for employee identity, organizational policy, device posture, and the access rules the employer has defined. Services and internal tools accept the Enterprise IdP for SSO, and the relevant clients and authorization servers are configured for ID-JAG. Employees move across authorized services without interactive re-authorization at each boundary.
This is also the most operationally mature context for ID-JAG because the infrastructure already exists: SSO trust is established, policy governance is in place, and authorization servers are already configured to accept the IdP. ID-JAG is an extension of what is already there.
CIAM and Product Platforms
A CIAM platform or product suite has its own identity graph. Users join through self-serve signup, enterprise federation, social login, or direct invitation. The platform is the authoritative issuer for those identities, regardless of which upstream directory any individual user came from. It manages the tenant relationships, the permission model, and the lifecycle of access across the product’s surfaces.
That identity governance authority is the same kind of authority an Enterprise IdP holds for its own subjects. When the platform acts as an IdP and downstream services within the ecosystem already trust it directly for SSO and subject resolution, the same immediate-IdP logic applies. A common shape is federation chaining: the user may authenticate upstream with an enterprise workforce IdP, but the CIAM platform is still the IdP that downstream product services trust directly for SSO and subject resolution. In that case, the CIAM platform, not the upstream workforce IdP, is the issuer that matters for ID-JAG at that boundary.
That trust relationship also means the CIAM platform has to own subject linking carefully. If the upstream workforce IdP uses pairwise subject identifiers or the product has to normalize identities across multiple upstream directories, the CIAM platform must map those upstream identities into the product-local subject identifier the downstream authorization server expects. That mapping burden is part of what it means for the product IdP to be the immediate IdP at that boundary.
This covers the full scope of identities a B2B SaaS product actually serves: workforce users who arrive via enterprise federation, users who joined before enterprise federation existed, external collaborators, partners, API developers, and customers who are themselves end-users rather than employees. The product governs all of these. The Enterprise IdP governs the workforce subset. Both can participate as issuers for the identities they are authoritative over where the downstream RAS already trusts them for SSO and subject resolution.
None of that removes the receiving authorization server’s sovereignty. The product IdP being the immediate IdP does not obligate the downstream authorization server to accept every assertion it issues. The receiving authorization server still decides whether to honor, narrow, or reject the grant under its own policy.
Two concrete product shapes make that immediate-IdP distinction especially clear.
Agentic workflows. An enterprise employee may launch the workflow, but the SaaS platform still has to govern product-local agent permissions, approval rules, runtime duration, tool access, and audit across the user-to-agent-to-tool chain. The workforce IdP can authenticate the employee. Where the downstream product services already trust the product or CIAM IdP directly for SSO and subject resolution, that product IdP is often the right system to issue the identity assertion they consume, because it owns the tenant model and product-local account context those services use as inputs to their own authorization decisions.
Admin and support elevation. A workforce IdP can prove who the support engineer is, but it usually does not own the ticket context, tenant scoping, break-glass policy, approval window, or product-local controls that determine what elevated support access should mean. Where the downstream product services already rely on the product IdP for SSO and subject resolution, that product IdP can issue a product-domain identity assertion that carries the right local subject and tenant context into the downstream token request, leaving the downstream services to enforce support access under their own bounded workflow rules rather than a generic employee entitlement.
Platform and Internal Service Identity
A platform may operate its own IdP as the trust anchor for a set of internal gateways, services, or API surfaces. Those services are configured to trust the platform IdP for authentication, and where the receiving authorization servers also accept that issuer for ID-JAG, the same trust pattern can remove per-service interactive flows. Here too, the platform IdP may itself federate upstream to a workforce IdP while remaining the immediate IdP the downstream systems already trust for SSO and subject resolution.
This is the architectural shape for microservice architectures, API gateway patterns, and internal developer platforms where the platform IdP governs service-to-service identity and access. The key point is that the downstream systems trust the platform IdP directly. The same pattern also appears in gateway bridge designs, where a platform gateway sits between upstream enterprise identity and downstream product or partner APIs and has to translate that identity into product-local tenant context and downstream audience-specific assertions.
Personal and Developer Identity
Developer toolchains, package registries, cloud provider CLIs, and similar surfaces follow the same trust logic. A developer authenticates to a central platform, such as a cloud identity provider, source-code hosting platform, or internal developer portal, and that platform becomes the immediate IdP that downstream tooling and registries already trust for SSO and subject resolution. The same ID-JAG trust pattern applies without requiring enterprise infrastructure: what matters is the established SSO trust relationship between that developer identity platform and the downstream authorization servers, not whether the platform is backed by an enterprise workforce IdP.
A concrete shape: a developer authenticates to a source-code hosting platform. A CI pipeline needs to push an artifact to a registry that already accepts that platform as its SSO IdP. The pipeline exchanges the platform-issued identity token into an ID-JAG via RFC 8693, then presents it as the authorization grant to the registry’s token endpoint via RFC 7523. The registry issues a scoped access token for the push without requiring an interactive redirect or a separate developer credential. The hosting platform is the immediate IdP because the registry already trusts it for SSO and developer subject resolution, the same relationship that backs the developer’s interactive login.
This is the context that most directly demonstrates the pattern is not bounded by enterprise deployment. The developer case satisfies the same trust constraint (a trusted issuer, a configured client, established policy) while the identity source and governance model are entirely different.
Agentic Systems
Agents make the issuer model harder to compress because three different identity questions appear at once: who the employee is, what product-local account and tenant context the downstream services recognize, and what software is actually executing. The workforce IdP may authenticate the employee. The product or platform IdP may still be the identity system that downstream services trust directly for subject and tenant context. A workload identity layer may separately prove the executing software.
That separation matters because downstream services rarely authorize against “workforce identity” in the abstract. They authorize against the local account, tenant, and product relationship they understand, while other parts of the stack may separately care about the executing workload. The useful IAM move is to keep those roles distinct instead of pretending one issuer is authoritative for all of them.
Agents also make the cross-domain boundary much more obvious. A workflow that starts inside one SaaS product often does not stay there: it may need to read from a ticketing system, update a CRM record, open a case in an ITSM tool, or call other enterprise APIs that live under different authorization servers. This is where the Cross-App Access label fits especially well. Once an agent has to move across application boundaries, it needs a shared trust anchor those downstream systems already recognize. In many enterprise deployments that shared trust anchor is the Enterprise IdP, even if a product or platform IdP still governs local tenant context inside its own trust domain.
A related question in agentic and platform architectures is whether ID-JAG chains across multiple hops. The recommendation is that deployments treat each trust boundary as requiring its own ID-JAG from the immediate IdP trusted at that boundary, rather than propagating a single assertion through the whole stack. In a three-tier architecture where a workforce IdP federates into a CIAM platform that in turn is trusted by downstream microservices, the CIAM platform issues an ID-JAG for the downstream hop. That ID-JAG is scoped to the trust relationship between the CIAM platform and those services; it does not carry the upstream workforce assertion forward as the operative grant. Each boundary has its own issuer, its own trust relationship, and its own grant.
That is the useful distinction for this post. The current ID-JAG draft is narrower than the full agent stack: it is an end-user identity assertion from the IdP the receiving authorization server already trusts for SSO and subject resolution. But that still means the issuer that matters at a given boundary may not be the top-level workforce IdP. In many product deployments, the CIAM or internal platform IdP sits downstream of workforce federation and is still the right ID-JAG issuer for the services inside its own trust domain, because those services already trust it directly at the relying-party boundary, even though it is not the system that originally authenticated the employee and not the system that proves the executing software.
Why Not Just Token Exchange and JWT Grants?
RFC 7523 defines a generic JWT bearer authorization grant profile. It does not assume the issuer is an identity provider, but it also does not eliminate trust requirements. The receiving authorization server still has to decide which issuers it accepts, how it validates claims, and what additional policy applies.
If you combine RFC 8693 token exchange with RFC 7523, you can build something that looks superficially similar to ID-JAG. The problem is that the generic stack leaves too much of the trust model, payload shape, and security behavior to local convention.
The reason that matters to this post is simple: ID-JAG is not just another way to package the same flow. It is a profile that narrows several places where a hand-rolled composition is easy to get wrong.
RFC 7523 is not missing trust altogether, and careful deployments do configure issuers they trust. What it does not provide is a standard IdP role, a defined payload profile, or specified security behavior for this cross-domain trust pattern.
- It narrows the trust model: the issuer is the IdP the receiving authorization server already trusts for SSO and subject resolution, not an arbitrary JWT signer. That established SSO relationship narrows subject mapping work, though it does not eliminate it: in pairwise-pseudonymous or multi-registration deployments the IdP still has to ensure the
subin the ID-JAG is the subject identifier the receiving authorization server expects for that user. - It narrows the payload semantics: audience,
client_id, tenant context, and subject alignment are all more explicit than in a generic composition. - It narrows the security behavior: sender-constraining continuity, resource and scope handling, and refresh behavior are profiled instead of left to local convention.
So the value of ID-JAG is not that generic JWT grants and token exchange are incapable of expressing a similar flow. The value is that ID-JAG turns a hand-rolled composition into a recognizable profile with tighter trust, clearer claim semantics, and fewer security ambiguities.
The Claim Worth Making
The constraint in ID-JAG is not enterprise branding. It is the existence of an issuer, client, and policy relationship under which the receiving authorization server is willing to accept an end-user identity assertion as a grant. In the current draft, that issuer is the IdP the receiving authorization server already trusts for SSO and subject resolution. That can be an enterprise workforce IdP, but it can also be a CIAM platform or an internal service IdP when those systems are the immediate IdPs for the downstream services in question.
That constraint is a feature, not a limitation. It gives the protocol a governance anchor. The receiving authorization server is not evaluating arbitrary claims from unknown issuers. It is evaluating assertions from an issuer it has already decided to trust for this category of grant, while still applying its own local policy.
Enterprise IdPs are the right issuers for workforce identity and enterprise-managed policy. Product or platform IdPs may be the right issuers for the local identities and relationships they govern inside their own ecosystems, including cases where they federate upstream to a workforce IdP but remain the direct SSO authority for downstream services.
Framing ID-JAG as only a top-level workforce IdP extension narrows the pattern unnecessarily. Framing it as a generic multi-issuer substrate goes too far the other direction. The stronger claim is that the pattern can extend beyond classic enterprise deployments wherever the downstream authorization server already trusts that issuer as its SSO IdP and is configured for the grant.
Put differently: the immediate IdP trusted by the downstream authorization server may not be the top-level workforce IdP. In many product and platform deployments, that immediate IdP is the CIAM or platform identity layer that federates upstream workforce identity but remains authoritative for the downstream trust boundary.
If CIAM, platform identity, or developer toolchain deployments are part of your use case for this pattern, now is the time to raise them in the working group. The draft is still moving and the text is still being shaped. The more concrete deployment examples the working group has on the table, the better the specification can reflect the full range of contexts where this trust pattern actually applies.