IETF · 31 October 2026
draft-ietf-oauth-identity-assertion-authz-grant-06
See draft (Parecki et al.; informally called XAA)
Identity Assertion JWT Authorization Grant (draft-ietf-oauth-identity-assertion-authz-grant-06) is WG draft, 31 October 2026. This is the emerging 'enterprise agent may call SaaS APIs as the employee' path that scales past per-tool OAuth popups. Still a draft; pin versions and test interoperability.
At a glance
Actors
01
An enterprise app or AI agent already has an SSO session with the company IdP and needs to call another app's API on the user's behalf without a second OAuth consent circus at every SaaS. draft-ietf-oauth-identity-assertion-authz-grant-06 (31 October 2026, expires 4 May 2027) provides that mechanism and is informally called Cross-App Access (XAA).
This does not replace CIBA: use CIBA when a specific action needs a human on a phone; XAA when IT policy already authorized the connection. Still a WG draft; vendors (Okta, Auth0) already document XAA for agents and MCP enterprise-managed authorization.
02
The enterprise IdP is the policy brain: it decides whether this requesting app may obtain a grant for that resource app. The resource app's AS already trusts the IdP for SSO; it now also trusts ID-JAGs as RFC 7523 assertions. The user is often not interactively prompted. That is a feature for IT and a hazard if policy is too broad.
03
Requesting app exchanges an ID Token (or refresh token) at the IdP via RFC 8693 for an Identity Assertion JWT Authorization Grant (ID-JAG) whose audience is the resource app's AS — not the requesting client (unlike an ID Token). It redeems the ID-JAG at that AS via RFC 7523 for an access token. Draft-05 adds mTLS certificate binding beside DPoP, requires jwt-dpop for a DPoP-bound ID-JAG, and allows a key-bound ID-JAG to replace client authentication at the resource AS. Authors: A. Parecki, K. McGuinness, B. Campbell.
04
Flow 1
User has an SSO session. Requesting app holds an ID Token from the enterprise IdP.
App token-exchanges at the IdP: subject=ID Token, requested grant for resource AS.
IdP policy allows or denies. On allow, ID-JAG issued (aud=resource AS).
App redeems ID-JAG at the resource AS (jwt-bearer). Access token for the SaaS API is issued.
App/agent calls the SaaS RS. No second consent screen unless policy demands it.
05
Authorization brokered by the identity provider the resource already trusts for SSO. Extends the IdP from authentication into cross-domain API access. User identity is in the grant; the access token is authorization at the resource AS.
06
XAA is a profile of that pattern with the IdP in the middle.
Mints the ID-JAG.
ID Token (or refresh) is the subject_token. Do not send the ID Token to the SaaS API.
Enterprise-managed MCP authorization often maps onto XAA so employees do not OAuth-popup every tool.
Different control: per-action human approval vs IT-preapproved connections.
07
If the IdP allows 'any internal agent → any SaaS', you have automated confused deputy at enterprise scale. Scope the connections.
If you redeem a token whose aud is the requesting app, you are presenting an ID Token. The grant's aud must be the resource AS.
08
draft-ietf-oauth-identity-assertion-authz-grant-06, 31 October 2026, expires 4 May 2027, OAuth WG. https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/. Draft-06 only changes the IdP subject-token validation error from invalid_grant to invalid_request. Pin versions; test vendor interop. Not an RFC.
Pin draft-06 (31 October 2026, expires 4 May 2027). Draft-05 (30 October 2026) added mTLS certificate binding beside DPoP for the ID-JAG, requires the jwt-dpop grant type for DPoP-bound ID-JAGs, and allows a key-bound ID-JAG to replace client authentication at the resource AS. Draft-06 changes the IdP error for a subject token that fails validation from invalid_grant to invalid_request. This does not replace CIBA: use CIBA when a specific action needs a human on a phone, XAA when IT policy already authorized the connection.