---
title: "Enabling Cross App Access for SAML-Based Resource Apps"
description: "Cross App Access (XAA) lets applications using existing SAML federation obtain API access without migrating to OpenID Connect (OIDC). An agent presents a short-lived Identity Assertion Authorization Grant (ID-JAG), which the resource authorization server validates, resolves to a user, and exchanges for its own access token; SAML processing remains upstream. For SAML identity resolution, implementations must validate the saml-nameid sub_id and match issuer, NameID, and sp_name_qualifier rather than relying on NameID alone. The guide recommends binding iss to a registered SAML connection before verifying the JWT against that connection’s JWKS, then checking typ, aud, and client_id and applying local scope policy. It also walks through Okta configuration and xaa.dev checks that redeem the ID-JAG, call the API, and export conformance results."
---

# Enabling Cross App Access for SAML-Based Resource Apps

[Okta](https://yomu.fyi/company/okta) · Updating authorization server metadata · Jul 3, 2026

**Type:** Tutorial

## Summary

Cross App Access (XAA) lets applications using existing SAML federation obtain API access without migrating to OpenID Connect (OIDC). An agent presents a short-lived Identity Assertion Authorization Grant (ID-JAG), which the resource authorization server validates, resolves to a user, and exchanges for its own access token; SAML processing remains upstream. For SAML identity resolution, implementations must validate the saml-nameid sub\_id and match issuer, NameID, and sp\_name\_qualifier rather than relying on NameID alone. The guide recommends binding iss to a registered SAML connection before verifying the JWT against that connection’s JWKS, then checking typ, aud, and client\_id and applying local scope policy. It also walks through Okta configuration and xaa.dev checks that redeem the ID-JAG, call the API, and export conformance results.

## Context

SAML-federated applications may need to let applications or agents access their APIs without replacing their existing SAML integration with OIDC. Because SAML applications do not typically provide a corresponding sub claim for direct user mapping, the resource authorization server must handle SAML-specific identity and security requirements.

## Approach / What changed

Use the ID-JAG as the artifact crossing from the identity provider to the resource domain. Bind its iss to a registered SAML connection, verify the JWT with that connection’s JWKS, validate the required claims, resolve the user from the complete saml-nameid identifier, apply local scope policy, and issue an access token. The guide also provides Okta setup and xaa.dev verification steps.

## Takeaways

- SAML user resolution uses sub\_id in saml-nameid format and must match the SAML issuer, NameID, and sp\_name\_qualifier; NameID alone may not uniquely identify a user.
- The resource authorization server should bind iss to a registered SAML connection before verifying the ID-JAG signature against that connection’s JWKS, then validate typ, aud, and client\_id.
- After resolving the user, the server issues an access token according to local policy; the guide explicitly says not to issue a refresh token.

**Tags:** [Authentication](https://yomu.fyi/topic/authentication), [OAuth 2.0](https://yomu.fyi/topic/oauth-2-0), [SAML](https://yomu.fyi/topic/saml)

- Source: [Okta](https://developer.okta.com/blog/2026/07/03/cross-app-access-saml)
- Source URL: https://developer.okta.com/blog/2026/07/03/cross-app-access-saml
- Ingested by Yomu: 2026-09-09T08:43:00.419Z

[Read original post](https://developer.okta.com/blog/2026/07/03/cross-app-access-saml)