Documentation
Documentation
SAML Cross App Access Overview
Not every enterprise runs on OIDC. Many still federate with SAML 2.0, and those organizations should not have to re-platform their identity stack to adopt Cross App Access.
XAA supports a SAML path built on draft-ietf-oauth-identity-assertion-authz-grant-04 §4.5, the protocol transition that turns a signed SAML assertion into an ID-JAG. Once you have the ID-JAG, the rest of the flow (the JWT Bearer grant and the API call) is identical to the OIDC path.
Use this if your users authenticate to your app through SAML SSO and you want that same login to authorize downstream API access, without adding an OIDC stack. If your app already uses OIDC, use the OIDC flow instead. It is one step shorter.
The five steps
The SAML path has five steps. Steps 1 to 3 are SAML-specific; steps 4 and 5 are the same standard OAuth steps the OIDC flow uses.
| # | Step | Spec | What happens |
|---|---|---|---|
| 1 | SAML SSO | SAML 2.0 | The user signs in at IdenX; your SP receives a signed <saml:Assertion> |
| 2 | Assertion → Refresh Token | §4.5 ① | Exchange the bare assertion for an opaque Refresh Token at the IdP |
| 3 | Refresh Token → ID-JAG | §4.5 ② | Exchange the Refresh Token for an ID-JAG carrying the SAML identity |
| 4 | JWT Bearer Grant | RFC 7523 | Present the ID-JAG to the Authorization Server for an access token |
| 5 | API Call | RFC 6750 | Call the Resource Server with the access token |
Why two token exchanges?
The OIDC path exchanges the ID Token for an ID-JAG in a single call. The SAML path splits this into two, for a concrete reason:
- A SAML assertion is a one-time, short-lived proof of a single sign-on event. It is not meant to be replayed.
- Step 2 trades it once for a longer-lived Refresh Token, which becomes the durable handle for the user's authenticated session.
- Step 3 then mints an ID-JAG from that Refresh Token whenever the app needs one.
The Refresh Token issued in Step 2 is single-use for minting an ID-JAG. The IdP revokes it the moment it issues the ID-JAG in Step 3, so a stolen Refresh Token cannot be exchanged twice.
How the SAML identity travels: sub_id
The one meaningful difference between a SAML ID-JAG and an OIDC ID-JAG is how the subject is expressed.
- OIDC carries a plain
subclaim (the user's identifier at the IdP). - SAML carries a structured
sub_idclaim withformat: "saml-nameid", per §3.2.1. It preserves the SAML NameID and its qualifiers so the Resource Server can resolve the same enterprise user your IdP asserted.
Everything downstream of the ID-JAG reads sub_id instead of sub: both the Authorization Server's validation and the Resource Server's user resolution use it. The Token Structure reference documents both forms.
Where to go next
Register your SAML app with Register Your App: register your Service Provider with IdenX and get the credentials for Steps 2 through 5.
Walk the flow with Step 1: SAML SSO: each of the five steps with real requests and responses.
Just want to test? Run the whole flow interactively, no integration code required:
- Test Your Resource App: register a SAML resource, then run the guided five-step flow end to end.
- Test Your Requesting App: redeem a SAML-derived ID-JAG your own IdP mints against a hosted Resource Server, and export a server-side conformance log.
On this page