Enterprise SaaS / IdP-brokered

A company agent needs Slack, Google, or another SaaS the IdP already federates. The IdP brokers the grant (XAA / ID-JAG) instead of sending the human through a second OAuth circus at every app.

When you see it

Enterprise Copilot or a custom agent that files a ticket in ServiceNow and posts to Slack under the employee's identity, with admin policy deciding which apps are pre-approved. The user signed into the company IdP this morning; the agent should not pop a new consent screen per SaaS if policy already allows the connection.

Actors and trust

Employee (user)User
Has an SSO session at the company IdP. May never see a second consent if policy pre-approves the app connection.
Company agent / appAgent instance
Already registered at the IdP. Not a portable AAuth identity; it is an enterprise OAuth client.
Company IdPOther
Issues an identity-assertion JWT authorization grant (ID-JAG) for the target app's AS.
SaaS authorization server + APIResource
Already trusts this IdP for SSO. Redeems the JWT grant (RFC 7523) for an access token to its own API.

Topology

EmployeeCompany IdPCompany agentSaaS ASSaaS API

Employee→ SSO session (OIDC) →Company IdP
Company agent→ Request ID-JAG / identity-chaining grant; aud = SaaS AS →Company IdP
Company IdP→ JWT authorization grant →Company agent
Company agent→ RFC 7523 JWT bearer grant →SaaS AS
SaaS AS→ Access token for this SaaS →Company agent
Company agent→ Call Slack / Google / … →SaaS API

IdP already has the user session. It mints a JWT grant for the SaaS AS; the agent never collects a second password.

Primary

Cross-App Access (ID-JAG)
ID-JAG / Cross-App Access — WG draft.
Identity chaining
General form; RFC Editor queue, no RFC number yet.
OpenID Connect Core

Optional

JWT authorization grants
RFC 7523 — the JWT bearer grant the SaaS AS redeems.
Token Exchange
RFC 8693 — often the mechanism at the IdP.
FAPI 2.0
When the target API is high-risk.
AIMS (agent auth BCP)draft / churn
Individual draft — expect churn.
AS issuer identification
RFC 9207 mix-up defenses once two ASes are in play.

Do not use

AAuthdraft / churn
Enterprise SaaS APIs expect OAuth tokens from an AS they already trust, not Signature-Key.
Per-SaaS password or a user refresh token harvested at install time
The IdP is supposed to broker this. Storing a Google refresh token in the agent bypasses enterprise policy.

Why these, and not those

XAA / ID-JAG is the IdP-brokered profile of 'the user is already signed in here; mint a grant the other app's AS will accept.' Identity chaining is the general two-AS version of the same idea. OIDC is how the IdP authenticated the employee. FAPI 2.0 if the SaaS is high-risk (open banking, payments). This is not AAuth p2p (there is very much an AS in the path) and not MCP (the wire to Slack is Slack's API, not an MCP session). AIMS tells you to compose these RFCs rather than invent a company-specific token.

Related flows

Sequence diagrams, not this topology cut. All flows