LoginSign Up
← Back to all sparks
Okta logo

Okta

INFRA · APISDEVOPS
Velocity5.0

Identity and access management platform

www.okta.com ↗

Okta is documenting Cross App Access into every federation shape it supports

identitycross-app-accessai-agentsoidcsamldeveloper-sdks
◆Current state
Okta's developer channel is running two threads at once. The dominant one is Cross App Access — the Identity Assertion Authorization Grant that lets an application or agent reach a third-party API on behalf of a user by exchanging tokens from an existing SSO trust. Since XAA was introduced in April, the output has been a systematic matrix of adoption guides: SAML requesting apps, SAML resource apps, and now the OIDC requesting and resource sides, plus listing XAA connections on the Okta Integration Network. The second thread is SDK and tutorial work, of which the Angular SDK going fully standalone is the substantive item.
◆Where it's heading
This is a feed of developer-education posts rather than release notes, so it reads cadence rather than shipping — but the shape of the education is itself the signal. Okta is not adding new XAA capability; it is removing every remaining excuse not to adopt it, one federation topology at a time, so that neither a SAML shop nor an OIDC shop has to migrate first. The Angular SDK release points the same direction from the client side, dropping NgModule for standalone providers and function guards so the SDK matches how current Angular applications are actually written.
◆Prediction
With OIDC and SAML now covered on both the requesting and resource sides, the remaining gaps in the matrix are framework SDKs and the agent runtimes themselves — expect XAA walkthroughs for more languages and agent frameworks in the vein of the earlier C# MCP post, rather than a new grant type.

◆Recent moves

  1. 22d ago

    Supercharge Auth with Signals and the New Okta Angular SDK

    The Okta Angular SDK drops NgModule entirely — no importProvidersFrom wrapper, and guards become plain functions — bringing it in line with how standalone Angular applications are structured. It is a modernization of an existing integration path rather than new authentication capability, but it removes the boilerplate mismatch that made the SDK feel dated against current Angular projects.

    View source ↗
  2. 23d ago

    Add Cross App Access to Your OIDC Resource Application

    The resource-application half of Cross App Access for OIDC federations: how an app that already trusts a customer's IdP for SSO reuses that same trust to authorize API access. Paired with the requesting-app guide days earlier, it completes the OIDC side of the same matrix Okta had already filled in for SAML.

    View source ↗
  3. 26d ago

    Add Cross App Access to Your OIDC Requesting Application

    The requesting-application half of Cross App Access for OIDC, turning on the detail that it is the refresh token from sign-in, not the ID token, that gets exchanged to reach a third-party app. Continues the pattern of covering each federation topology separately so adopters never have to change protocols to use XAA.

    View source ↗
  4. 27d ago

    I Found My Coordinates: Code, Community, and Okta

    A first-person career post from the Builder Advocacy team with no product content. It is the second narrative of its kind in this window, marking the blog's drift toward community storytelling alongside the XAA technical push.

    View source ↗
  5. 1mo ago

    Build a Flask App with Okta for Secure OIDC Login and Authorized API Calls

    A standard OIDC-plus-Flask integration tutorial covering ground Okta has documented for years. It sits outside the XAA thread and signals no change in what the platform can do.

    View source ↗
  6. 2mo ago

    Enable Your SAML Requesting App for Cross App Access

    Covers the requesting-app side of Cross App Access for SAML federations, the complement to the earlier guide aimed at resource apps. Together the two close the loop so SAML shops can adopt XAA without migrating to OIDC first.

    View source ↗