Okta Developer

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

Tue, 28 Jul 2026 00:00:00 -0500

Python syntax and the flexibility of the Flask microframework make it a popular choice for quickly building web applications. While Flask provides the essentials to get you started, you’ll need to tackle two critical pieces yourself: secure user authentication and authorized access to your backend services. After all, how do you securely sign users into your application? And once they’re signed in, how does your app fetch data from a backend service that only serves authorized requests?

This tutorial shows you how to solve both. You’ll build a Flask dashboard app that signs users in with Okta using OpenID Connect (OIDC). Once signed in, the app uses the resulting OAuth 2.0 access token to call a separate backend API that only responds to authorized requests, a common pattern where a web app needs to fetch data from a protected backend service. You’ll use Authlib, an OIDC client library, to configure the Authorization Code flow with PKCE automatically. You’ll also learn how to add a custom scope to the access token and validate it on the backend to control what data the API returns.

Check out the complete source code on GitHub and get started without setting it up from scratch.

Table of Contents

Build a Flask app with OIDC authentication
Create an app integration in the Okta Admin Console
Enable self-service user registration
Add secure user login to a Flask application with Okta
Call a protected API with OAuth scoped tokens
Learn more about OAuth and OIDC

Build a Flask app with OIDC authentication

In this tutorial, you’ll build a simple dashboard application and learn how to:

Securely sign users in to view their profile information using Okta as the OpenID Connect identity provider.
Use Authlib to configure the Authorization Code flow with PKCE automatically, following OAuth 2.1 security best practices.
Add a feature for new users to self-register for an account directly from the sign-in page.
Enable authenticated users to interact with a protected API using access tokens.

Prerequisites

Python 3.14 or later and pip installed
An Okta Integrator Free Plan

Create an app integration in the Okta Admin Console

Before you begin, you’ll need an Okta Integrator Free Plan account. To get one, sign up for an Integrator account. Once you have an account, sign in to your Integrator account. Next, in the Admin Console:

Go to Applications > Applications
Click Create App Integration
Select OIDC - OpenID Connect as the sign-in method
Select Web Application as the application type, then click Next
Enter an app integration name
Configure the redirect URIs:
- Sign-in redirect URIs: http://localhost:5000/authorization-code/callback
- Sign-out redirect URIs: http://localhost:5000
In the Controlled access section, select the appropriate access level
Click Save

Where are my new app's credentials?

Creating an OIDC Web App manually in the Admin Console configures your Okta Org with the application settings.

After creating the app, you can find the configuration details on the app’s General tab:

Client ID: Found in the Client Credentials section
Client Secret: Click Show in the Client Credentials section to reveal
Issuer: Found in the Issuer URI field for the authorization server that appears by selecting Security > API from the navigation pane.

You’ll need these values for your application configuration:

OKTA_OAUTH2_ISSUER="https://dev-133337.okta.com/oauth2/default"
OKTA_OAUTH2_CLIENT_ID="0oab8eb55Kb9jdMIr5d6"
OKTA_OAUTH2_CLIENT_SECRET="NEVER-SHOW-SECRETS"

Your Okta domain is the first part of your issuer, before /oauth2/default.

NOTE: You can also use the Okta CLI Client or Okta PowerShell Module to automate this process. See this guide for more information about setting up your app.

Enable self-service user registration

User registration is vital for any application, and Okta makes the process quick and hassle-free. See Self-Service Registration for an overview of how it works. Setting this up involves two main steps:

Create a user profile policy - This policy defines the attributes a user must provide when self-registering. See the Okta documentation for detailed instructions.
Assign your application to the policy - This step is required; without it, the self-service registration flow will not activate for your app. See the product documentation for more details.

Now that you’ve configured your app integration in Okta and noted the required Okta application details, it’s time to create your Flask application.

Create a basic Flask web application

First, you’ll create a project folder and a Python virtual environment, then install the necessary dependencies.

Create a project folder named flask-web-app and a subfolder called venv.
Open a terminal window in the project folder and create a Python virtual environment
```
python -m venv venv
```
Activate the virtual environment. Use the command that corresponds to your operating system.
```
# On macOS/Linux
source venv/bin/activate

# On Windows
venv\Scripts\activate.bat
```

With your environment active, install the required libraries:

pip install Authlib==1.6.1 Flask[async]==3.1.1 python-dotenv==1.1.1 requests==2.32.4 okta-jwt-verifier==0.3.0

Configure Flask environment variables

To keep sensitive credentials out of source control, you’ll store them in a .env file and load them into the application’s configuration. This practice prevents hard-coding secrets directly into your source code. Make sure to add .env to your .gitignore file to prevent accidentally committing your credentials to source control.

Create a file named .env in the project root and add your Okta application’s configuration details. Replace the placeholders with your actual values.
```
OKTA_CLIENT_ID={yourClientId}
OKTA_CLIENT_SECRET={yourClientSecret}
OKTA_BASE_URL=https://{yourOktaDomain}
```

Create a config.py file in the project root. This file reads the values from .env and constructs the OIDC metadata URL, which the application uses to fetch endpoints from Okta.

import os

OKTA_CLIENT_ID = os.getenv('OKTA_CLIENT_ID')
OKTA_CLIENT_SECRET = os.getenv('OKTA_CLIENT_SECRET')
OKTA_BASE_URL = os.getenv("OKTA_BASE_URL")
OKTA_METADATA_URL = f"{OKTA_BASE_URL}/.well-known/openid-configuration"

Implement the OIDC authentication logic

Next, create the main application file, app.py, in your project’s root directory. This file holds the core logic for handling OIDC authentication. Paste the following code into it to configure the basic application.

from flask import Flask, render_template, url_for, redirect, session
from authlib.integrations.flask_client import OAuth
from dotenv import load_dotenv
import os
import requests

load_dotenv()

app = Flask(__name__)
app.secret_key = os.urandom(24)

app.config.from_object('config')

@app.route("/")
def index():
    return render_template('index.html')

if __name__ == "__main__":
    app.run(debug=True)

Initialize the Okta OIDC client

To set up the connection to Okta, add the following code to the bottom of your app.py file. This code initializes an OAuth object and registers the Okta application as a remote provider.

# Create a registry with an OAuth object
oauth = OAuth(app)

# Register a remote application
oauth.register(
    name='okta',
    client_id=app.config['OKTA_CLIENT_ID'],
    client_secret=app.config['OKTA_CLIENT_SECRET'],
    server_metadata_url=app.config['OKTA_METADATA_URL'],
    client_kwargs={
        'scope': 'openid profile email offline_access',
        'code_challenge_method': 'S256'
    }
)

The first parameter in the register() method (in this case, Okta) is the name of the remote application. You’ll later access the remote application with oauth.okta to handle all the OIDC-related functions.

The client_kwargs dictionary passes extra parameters to the authorization request. Because the code_challenge_method is present, the Authlib library automatically uses the PKCE flow, which enhances security.

Build Flask routes for OIDC authentication

The sign-in process begins when the user clicks the Login button, which redirects the browser to the Okta-hosted Sign-In page.

After the user signs in, Okta redirects the browser to the configured sign-in redirect URI with an authorization code. Authlib then exchanges that code for tokens and automatically calls Okta’s userinfo endpoint to retrieve the user’s profile. Similarly, after a user signs out, Okta redirects the browser to the sign-out redirect URI.

Let’s start by creating a simple HTML page that allows the user to log in. This page will display a sign-in button for signed-out users and a sign-out button for logged-in users, along with profile information.

Add the /login route to your app.py file. This endpoint serves as the entry point for the authentication flow. It constructs the authorization redirect URI and sends the user’s browser to the Okta-hosted Sign-In page to begin the OIDC process.
```
@app.route('/login')
def login():
    redirect_uri = url_for('authorization_code_callback', _external=True)
    return oauth.okta.authorize_redirect(redirect_uri)
```
Next, implement the callback handler for the Redirect URI you configured in your Okta application (http://localhost:5000/authorization-code/callback). This handler processes the authorization code returned by Okta. Calling authorize_access_token() triggers Authlib to exchange the code for tokens and automatically call Okta’s userinfo endpoint. Both the userinfo and the full token are then stored in Flask’s session for use across requests.
```
@app.route('/authorization-code/callback')
def authorization_code_callback():
    token = oauth.okta.authorize_access_token()
    session['loggedInUser'] = token['userinfo']
    session['token'] = token

    return redirect('/')
```

Add the /logout route. This endpoint clears the local user session, signing the user out of the Flask application. It then constructs a redirect URL to Okta’s logout_endpoint, which terminates the user’s session with Okta, ensuring a complete and secure sign-out.

@app.route('/logout')
def logout():
    token = session.get('token')

    id_token_hint = None
    if token:
        id_token_hint = token.get('id_token')

    conf = oauth.okta.server_metadata
    logout_endpoint = conf.get('end_session_endpoint')

    session.pop('loggedInUser', None)
    session.pop('token', None)

    if logout_endpoint:
        logout_url = (
            f'{logout_endpoint}?'
            f'id_token_hint={id_token_hint}&'
            f'post_logout_redirect_uri={url_for("index", _external=True)}'
        )
        return redirect(logout_url)

    return redirect('/')

Finally, update the root route (/). This route now checks the session for a signed-in user and passes that information to the template.

@app.route("/")
def index():
    loggedInUser = session.get('loggedInUser')
    return render_template('index.html', user=loggedInUser)

With the back-end routes in place, you can now create the HTML template files to provide a user interface for signing in, signing out, and displaying profile data.

Step 1: Create a templates directory in your project root. Inside it, create an index.html file. This page will display a Login button for signed-out users and, for signed-in users, profile information with a Logout button.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Home</title>
    <link rel="stylesheet" href="{{ url_for('static', filename='css/index.css') }}" />
  </head>
  <body>
    <div class="wrapper">
      <nav class="main-nav" role="navigation" aria-label="Primary navigation">
        <div class="nav-left">
          <a href="/">Flask Web App</a>
        </div>
        <div class="nav-right">
          {% if user %}
          <a href="/fetch-users">Fetch Users</a>
          <a href="/logout">Logout</a>
          {% else %}
          <a href="/login">Login</a>
          {% endif %}
        </div>
      </nav>

      <main class="container">
        {% if user %}
        <section aria-label="User welcome" class="user-info">
          <h1>Welcome, {{ user.name or user.preferred_username or 'User' }}!</h1>
          <p>You have successfully logged in. You can now fetch and view user details.</p>
          <p>Click the button below to load the list of users.</p>
          <button onclick="location.href='/fetch-users'">Fetch Users</button>
        </section>

        {% else %}
        <section aria-label="Login prompt" class="user-info">
          <h1>Welcome to the Flask Web App</h1>
          <p>If you are seeing this, you are not logged in yet.</p>
          <p>This app uses OpenID Connect (OIDC) for secure login. After logging in, you will be able to access user-specific data.</p>
          <p>Click the login button below to get started.</p>
          <a href="/login" class="button-link">Login / Register</a>
        </section>
        {% endif %}
      </main>
    </div>
  </body>
</html>

Step 2: For styling, create a static/css directory in your project root. Inside it, create index.css and add the following code.

body,
html {
  height: 100%;
  margin: 0;
  padding: 0;
  font-family: "Segoe UI", Tahoma, Geneva, Verdana, sans-serif;
  line-height: 1.5;
  overflow-y: hidden;
}

nav.main-nav {
  position: fixed;
  top: 0;
  left: 0;
  right: 0;
  background-color: #2f2f2f;
  color: #f0f0f0;
  display: flex;
  justify-content: space-between;
  align-items: center;
  padding: 1rem 2rem;
  z-index: 1000;
}

nav.main-nav a {
  color: #f0f0f0;
  text-decoration: none;
  margin-left: 1.5rem;
  font-weight: 600;
}

nav.main-nav a:hover {
  color: #bfbfbf;
  text-decoration: underline;
}

.wrapper {
  display: flex;
  flex-direction: column;
  min-height: 100vh;
  max-width: 1000px;
  margin: 0 auto;
  padding: 5rem 2rem 0;
}

main.container {
  flex: 1 1 auto;
  padding: 2rem 0;
  display: flex;
  flex-direction: column;
}

section.user-info {
  background: transparent;
  padding: 1.5rem 0;
  margin-bottom: 2rem;
  color: #222222;
}

button,
a.button-link {
  background-color: #1a73e8;
  color: #fff;
  border: none;
  padding: 0.6rem 1.3rem;
  border-radius: 5px;
  cursor: pointer;
  font-size: 1rem;
  text-decoration: none;
  display: inline-block;
  margin-top: 1rem;
  font-weight: 600;
}

button:hover,
a.button-link:hover {
  background-color: #155ab6;
  color: #fff;
}

Run the Flask OAuth web app

You’re ready to test the sign-in and sign-out functionality.

Start the application with the Flask server.

flask run

Open a new terminal window and start the resource server.

flask --app resource-server.py run --port 5001

Open a browser and go to http://localhost:5000.
Click Login. The browser redirects you to the Okta Sign-In Widget.
After you sign in, Okta redirects you back to your application, and the page displays the signed-in user’s details.

Click Logout. The browser clears your session and returns you to the home page.

You’ve successfully added a secure authentication flow to your Flask app. Next, you’ll extend it to call a protected API using scoped tokens.

Call a protected API with OAuth scoped tokens

Using OAuth for API authorization is a modern security best practice. It allows you to use access tokens to interact with APIs to fetch and manage data securely. This section walks you through how to use a scoped access token to fetch data from your own resource server.

Every action on an endpoint that supports OAuth 2.0 requires a specific scope. In this example, your endpoint requires the specific scope api:read-users to return a list of sample users.

To include this scope in the tokens minted from Okta, follow these steps:

In your Okta Admin Console, navigate to Security > API.
Select your Authorization Server and go to the Scopes tab
Click the Add Scope button and enter api:read-users in the Name field.
Optionally, enter the Description and the Display Phrase
Click Create.

Now, when this scope is requested, Okta will include it in the tokens it issues.

Before creating the resource server, add an extra layer of security. You want your endpoint only to consume tokens intended for your server, preventing tokens issued for other services from being replayed or misused.

To do this, restrict the aud claim that Okta returns in the access token to your resource server. To achieve this:

In your Okta Admin Console, navigate to Security > API.
Select your Authorization Server. In the Settings tab, click Edit
Change the Audience field to http://localhost:5001 — this is where your resource server will be hosted

Build a protected users API

For this demo app, you’ll create a minimal resource server with a single route called fetch-users that returns a list of sample users.

Start by modifying the .env file. Add the variable that stores the domain of your resource server (in this case, http://localhost:5001):

OKTA_CLIENT_ID={yourClientId}
OKTA_CLIENT_SECRET={yourClientSecret}
OKTA_BASE_URL=https://{yourOktaDomain}
RESOURCE_SERVER_BASE_URL=http://localhost:5001

Now, modify the config.py file to include the resource server URL and the list of sample users. Replace the existing code with the following:

import os

OKTA_CLIENT_ID = os.getenv('OKTA_CLIENT_ID')
OKTA_CLIENT_SECRET = os.getenv('OKTA_CLIENT_SECRET')
OKTA_BASE_URL = os.getenv("OKTA_BASE_URL")
OKTA_METADATA_URL = f"{OKTA_BASE_URL}/.well-known/openid-configuration"
RESOURCE_SERVER_BASE_URL = os.getenv("RESOURCE_SERVER_BASE_URL")

SAMPLE_USERS = [
    {
        "id": 1,
        "name": "Alice Johnson",
        "firstName": "Alice",
        "lastName": "Johnson",
        "email": "alice.johnson@example.com"
    },
    {
        "id": 2,
        "name": "Bob Smith",
        "firstName": "Bob",
        "lastName": "Smith",
        "email": "bob.smith@example.com"
    },
    {
        "id": 3,
        "name": "Charlie Brown",
        "firstName": "Charlie",
        "lastName": "Brown",
        "email": "charlie.brown@example.com"
    }
]

Create a resource-server.py file in the project directory and add the following code:

from flask import Flask, request, jsonify
from okta_jwt_verifier import BaseJWTVerifier

app = Flask(__name__)

app.config.from_object('config')

ISSUER = app.config['OKTA_BASE_URL']
CLIENT_ID = app.config['OKTA_CLIENT_ID']
AUDIENCE = app.config['RESOURCE_SERVER_BASE_URL']
REQUIRED_SCOPES = {"api:read-users"}

async def verify_token():
    pass

@app.get('/fetch-users')
async def get_users():
    is_valid, error_response = await verify_token()

    if not is_valid:
        return error_response

    return jsonify(app.config['SAMPLE_USERS'])


if __name__ == "__main__":
    app.run(port=5001)

The endpoint returns sample users if the token is valid. Next, you’ll add token validation.

Now write the logic for token validation. You’ll validate the token’s issuer, audience, and client ID against your authorization server URL, resource server domain, and client ID. You’ll also verify that the api:read-users scope is present in the token’s scp claim.

Start with the verify_token function. First, check if the Authorization header is of type Bearer:

auth_header = request.headers.get("Authorization")

if not auth_header:
    return None, (jsonify({"error": "No token provided"}), 401)

parts = auth_header.split()
if parts[0].lower() != "bearer" or len(parts) != 2:
    return None, (jsonify({"error": "Authorization header must be Bearer token"}), 401)

Next, use Okta’s package to verify that the audience, issuer, and client ID in the token match your configuration:

token = parts[1]

try:
    jwt_verifier = BaseJWTVerifier(issuer=ISSUER, client_id=CLIENT_ID, audience=AUDIENCE)
    await jwt_verifier.verify_access_token(token)

    return True, None
except Exception as e:
    print(f"Token verification failed: {e}")
    return None, (jsonify({"error": "Invalid or Expired Token"}), 401)

Now add scope validation. Extract the claims from the token and check that the custom scope api:read-users is present in the scp claim. If the token doesn’t contain this scope, reject it and return an error. In the try block, before the return statement, add the following code:

_, claims, _, _ = jwt_verifier.parse_token(token)
token_scopes = set(claims.get("scp", []))
if not REQUIRED_SCOPES.issubset(token_scopes):
    return False, (jsonify({"error": "Insufficient Scope"}), 403)

print("Token is Valid!")

Once everything is done, your verify_token function should look like this:

async def verify_token():
    auth_header = request.headers.get("Authorization")

    if not auth_header:
        return None, (jsonify({"error": "No token provided"}), 401)

    parts = auth_header.split()
    if parts[0].lower() != "bearer" or len(parts) != 2:
        return None, (jsonify({"error": "Authorization header must be Bearer token"}), 401)

    token = parts[1]

    try:
        jwt_verifier = BaseJWTVerifier(issuer=ISSUER, client_id=CLIENT_ID, audience=AUDIENCE)
        await jwt_verifier.verify_access_token(token)

        _, claims, _, _ = jwt_verifier.parse_token(token)
        token_scopes = set(claims.get("scp", []))
        if not REQUIRED_SCOPES.issubset(token_scopes):
            return False, (jsonify({"error": "Insufficient Scope"}), 403)

        print("Token is Valid!")
        return True, None

    except Exception as e:
        print(f"Token verification failed: {e}")
        return False, (jsonify({"error": "Invalid or Expired Token"}), 401)

Extend the Flask app to interact with the resource server

With the configuration in Okta complete, the next step is to update your Flask application to request this scope. This ensures that the access token issued to the user includes the necessary permission to call the protected endpoint.

In your app.py file, find the oauth.register block and add api:read-users to the scope string within the client_kwargs dictionary.

 oauth.register(
     # ... other parameters
     client_kwargs={
         'scope': 'openid profile email offline_access api:read-users',
         'code_challenge_method': 'S256'
     }
 )

Add a new route, /fetch-users, to your app.py file. This endpoint uses the stored access token from the user’s session to make a secure GET request to the protected endpoint in the resource server. If successful, it passes the returned list of users to the index.html template for display.

@app.route('/fetch-users')
def fetchUsers():
    token = session.get('token')
    loggedInUser= session.get('loggedInUser')

    if not (token or loggedInUser):
        return redirect(url_for('login'))

    access_token = token.get('access_token')
       
    RESOURCE_SERVER_BASE_URL = app.config['RESOURCE_SERVER_BASE_URL']

    headers = {"Authorization": f"Bearer {access_token}"}
    resp = requests.get(f"{RESOURCE_SERVER_BASE_URL}/fetch-users", headers=headers)

    if resp.ok:
        data = resp.json()
        return render_template('index.html', user=loggedInUser, userList=data)

    else:
        return f"API request failed: {resp.status_code} {resp.text}", resp.status_code

Update the root route (/) to initialize the userList variable in the template. This prevents errors when the page first loads before any data is fetched. Replace the existing index function with the following code.
```
 @app.route("/")
 def index():
     loggedInUser = session.get('loggedInUser')
     return render_template('index.html', user=loggedInUser, userList=None)
```

Update the Flask UI to display protected data

Now, let’s modify the front end to add a button that triggers the API call and a table to display the returned user data.

Step 1: Open the templates/index.html file and replace its entire contents with the updated code below. This version adds a Fetch Users button for signed-in users and a table to display the user list when available.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Home</title>
    <link rel="stylesheet" href="{{ url_for('static', filename='css/index.css') }}" />
  </head>
  <body>
    <div class="wrapper">
      <nav class="main-nav" role="navigation" aria-label="Primary navigation">
        <div class="nav-left">
          <a href="/">Flask Web App</a>
        </div>
        <div class="nav-right">
          {% if user %}
          <a href="/fetch-users">Fetch Users</a>
          <a href="/logout">Logout</a>
          {% else %}
          <a href="/login">Login</a>
          {% endif %}
        </div>
      </nav>

      <main class="container">
        {% if user %}
        <section aria-label="User welcome" class="user-info">
          <h1>Welcome, {{ user.name or 'User' }}!</h1>
          <p>You have successfully logged in. You can now fetch and view user details.</p>
          <p>Click the button below to load the list of users.</p>
          <button onclick="location.href='/fetch-users'">Fetch Users</button>
        </section>

        {% if userList %}
        <section aria-label="Users table">
          <h2>Users List</h2>
          <div class="table-wrapper">
            <table>
              <thead>
                <tr>
                  <th>Email</th>
                  <th>First Name</th>
                  <th>Last Name</th>
                </tr>
              </thead>
            </table>
            <div class="table-body-scroll">
              <table>
                <tbody>
                  {% for user in userList %}
                  <tr>
                    <td>{{ user.email }}</td>
                    <td>{{ user.firstName }}</td>
                    <td>{{ user.lastName }}</td>
                  </tr>
                  {% endfor %}
                </tbody>
              </table>
            </div>
          </div>
        </section>
        {% endif %} {% else %}
        <section aria-label="Login prompt" class="user-info">
          <h1>Welcome to the Flask Web App</h1>
          <p>If you are seeing this, you are not logged in yet.</p>
          <p>This app uses OpenID Connect (OIDC) for secure login. After logging in, you will be able to access user-specific data.</p>
          <p>Click the login button below to get started.</p>
          <a href="/login" class="button-link">Login / Register</a>
        </section>
        {% endif %}
      </main>
    </div>
  </body>
</html>

Step 2: To style the new user table, open the static/css/index.css file and add the following CSS to the end of the file.

.table-body-scroll {
    max-height: 300px;
    overflow-y: auto;
    border-radius: 8px;
    border: 1px solid #d1d9e6;
    box-shadow: 0 0 6px rgba(0, 0, 0, 0.05);
  }
 
  table {
    border-collapse: collapse;
    width: 100%;
    background-color: #fff;
    color: #2c3e50;
    border-radius: 8px 8px 0 0;
    table-layout: fixed;
  }
 
  thead th {
    text-align: center;
    background-color: #e9f0fb;
    color: #1a3c72;
    font-weight: 700;
    padding: 0.75rem 1rem;
    border-bottom: 1px solid #d1d9e6;
    position: sticky;
    top: 0;
    z-index: 1;
  }
 
  td {
    text-align: center;
    padding: 0.75rem 1rem;
    border-bottom: 1px solid #e2e8f0;
    font-size: 1rem;
    word-wrap: break-word;
  }

Test the protected API integration

Ready to see it all work? Make sure both servers are running: the Flask app (flask run) and the resource server (flask --app resource-server.py run --port 5001). Open a browser, go to http://localhost:5000, sign in, and then click Fetch Users. A table should appear with a list of sample users returned from your resource server. If you see the user data, your integration is a success!

Your Flask application now has secure user authentication and can use an access token to interact with a protected API.

Learn more about OAuth and OIDC

If you’d like to learn more about the concepts covered in this tutorial, explore these official Okta resources:

Remember to follow us on LinkedIn, X and subscribe to our YouTube channel for more exciting content. We also want to hear from you about the topics you’d like to see and any questions you may have. Leave us a comment below!

Enable Your SAML Requesting App for Cross App Access

Fri, 17 Jul 2026 00:00:00 -0500

If you currently federate enterprise customers using Security Assertion Markup Language (SAML) and want to connect with third-party applications without migrating to OpenID Connect (OIDC), this Cross App Access (XAA) guide is for you.

The Identity Assertion Authorization Grant specification, the basis of XAA, was originally designed with OIDC in mind. To use it in SAML applications, you must accommodate specific security and uniqueness requirements. This guide details what you need to support and how to make resource requests to a third-party app using XAA.

Table of Contents

How XAA in SAML works
XAA implementation checklist for SAML-federated applications
Making cross-application requests from your SAML app securely
Configure your XAA SAML Requesting App in Okta
Learn more about Cross App Access, SAML, and OAuth 2.0

How XAA in SAML works

When an agent (like one running in Claude) needs API access, it presents an Identity Assertion Authorization Grant (ID-JAG). The ID-JAG is a short-lived JSON Web Token (JWT) issued by the Identity Provider (IdP) for your app’s user. You exchange the ID-JAG token for an access token to the resource application you’re connecting with.

The sequence diagram shown below describes the SAML XAA flow and how your application fits in. You’ll handle the flow in two parts: where your application requests the ID-JAG from the IdP using a refresh token, and where your app requests the access token from the ID-JAG from the third-party resource app’s authorization server.

XAA implementation checklist for SAML-federated applications

Follow the guide in this section to support XAA in your SAML application when your app connects to a third-party resource application. The XAA flow places the burden of token validation onto the IdP and the resource app’s authorization server. The initial SSO step remains the same; however, you’ll add three requests before getting an access token to make the resource API call.

Once the user completes signing in, you’ll:

Request an OAuth refresh token from Okta
Request the ID-JAG token from Okta
Request the OAuth access token from the third-party resource app’s OAuth authorization server

Request the refresh token

Your SAML application makes the initial SSO handshake and handles the SAMLResponse as usual. The ACS handler verifies the incoming payload and its digital signature, then extracts the underlying XML assertion. This assertion serves as the required credential for the subsequent exchange.

Immediately after validating the SAML response, in the same ACS request before redirecting the user onward, you’ll perform the first exchange. Base64-encode the assertion you extracted, then exchange it for a refresh token using Okta’s token endpoint. This exchange follows the OAuth 2.0 Token Exchange (RFC 8693) mechanism.

This step requires a credential in the request. Because you’re making a sensitive resource request, Okta requires a JWT signed with an asymmetric key pair as the credential – a private key JWT.

Follow the instructions in the Build a JWT for Client Authentication for your tech stack. The signed JWT becomes a client assertion in the request.

The refresh token HTTP request looks like this:

POST /oauth2/v1/token HTTP/1.1
Host: your-okta-domain.okta.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange&
subject_token=<base64url-encoded SAML assertion XML>&
subject_token_type=urn:ietf:params:oauth:token-type:saml2&
requested_token_type=urn:ietf:params:oauth:token-type:refresh_token&
scope=openid+offline_access&
client_id=<your_client_id>&
client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&
client_assertion=<your signed JWT>

The IdP (Okta) responds with the refresh token. The refresh token is opaque and long-lived. Persist the refresh token for the session; never persist or use the SAML assertion past this exchange.

Request the ID-JAG token

With the refresh token in hand, you have the credentials to request the ID-JAG token when your application needs resources from a third-party app. This exchange uses the same OAuth token exchange mechanism as the first step. You make the POST request to the same endpoint, Okta IdP, using the refresh token, and request the ID-JAG token type.

This request also requires a signed JWT as it’s requesting a sensitive resource.

The HTTP request looks like this:

POST /oauth2/v1/token HTTP/1.1
Host: your-okta-domain.okta.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange&
subject_token=<the refresh_token from prior step>&
subject_token_type=urn:ietf:params:oauth:token-type:refresh_token&
requested_token_type=urn:ietf:params:oauth:token-type:id-jag&
audience=<the resource app's authorization server issuer URI>&
resource=<the resource app's API base URL>&
scope=<the resource app's required scopes>&
client_id=<your_client_id>&
client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&
client_assertion=<your signed JWT>

The IdP responds with a short-lived, signed JSON Web Token (JWT), the ID-JAG, as the value in the access_token property within the payload.

Request the access token

Redeem the ID-JAG at the resource app’s authorization server’s token endpoint. The resource app’s authorization server handles the redemption request, not the IdP. This request uses the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants (RFC 7523). The ID-JAG is the assertion now, and you include the scopes required for the resource request. The scope matches the scopes requested in the ID-JAG request. The HTTP request looks something like:

POST /token HTTP/1.1
Host: the-resource-server.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <base64(resource_as_client_id:resource_as_client_secret)>

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&
assertion=<ID-JAG token>&
scope=todos.read

In the example HTTP request, the Authorization header uses the Basic scheme as a demo. Use the authorization scheme required by the resource application.

The response payload contains the access_token property, whose value is the access token. Use the access token to make the API resource request by using the value in the Authorization header. For example:

Authorization: Bearer <access_token>

Handle token expiration

ID-JAG tokens have a short timeline by design. When it expires, request a shiny new ID-JAG from the refresh token. Refresh tokens also have a lifespan. If the IdP rejects the refresh token due to expiration (you’ll see an invalid_grant error), then you need to obtain a new refresh token by having the user sign in via SSO again.

Making cross-application requests from your SAML app securely

With these steps complete, your SAML application is configured for Cross App Access. Agents can now authorize requests against your API while maintaining your existing production federation, eliminating the need for protocol migration.

You can now use Okta to make cross-application requests with your SAML app.

Configure your XAA SAML Requesting App in Okta

Let’s configure your SAML requester application in Okta. Before you begin, you’ll need:

Values from your app (we’ll walk through the values needed below)
An Okta Integrator Free Plan account. Sign up for a new account to test out the XAA feature
xaa.dev for testing your requesting app

Cross App Access is an early access feature in Okta. New Integrator Free Plan account types include XAA support. If you have a paid Okta org plan and the following options are missing, contact your representative.

Enable AI Agent Identity Assertion:

Navigate to Settings > Features > Early Access
Find AI Agent Identity Assertion and Agent to Agent Connections, and enable both

You’ll need an Okta application representing your requesting app.

Navigate to Applications > Applications

In the Create a new app integration model, select SAML 2.0 and press Next.

In General Settings:

App name: Enter a descriptive name for the app, for example, “Requesting App”.
Press Next to continue

In Configure SAML:

Single sign-on URL: Use the ACS URL of your requestor app, e.g., “https://requester-app-uri/saml/acs”
Audience URI (SP Entity ID): Use the SP Entity of your requestor, e.g., “https://requester-app-uri/saml/metadata”
Name ID format: select EmailAddress
Application username: select Email
Update application username on: select Create and update
Press Next to continue

Press Finish to create the Okta SAML 2.0 application.

After creating the app, you’ll see more configuration options for your Okta SAML 2.0 requesting app. You’ll make changes in more than one tab.

Sign On configuration

Select the Sign On tab. To the right, locate the View SAML setup instructions under the header SAML Setup, open the saml-doc file, and copy the Identity Provider Single Sign-On URL and Identity Provider Issuer. You will need these values in your requesting app setup. On the same page, make sure you download the X.509 certificate and add it back to your requester app as idp-cert.pem.

Assignments configuration

Navigate to the Assignments tab and make the following configuration changes:

Select Assign > Assign to People
Search for your test user and select Assign
Press Save and Go Back, then select Done

Now that we have the requesting app registered, it’s time to register a resource app on the Okta platform. You’ll also need an Okta application representing the resource app.

Navigate to Applications > Applications

In the Create a new app integration model, select SAML 2.0 and press Next.

In General Settings:

App name: Enter a descriptive name for the app, for example, “Resource App for Testing”.
Press Next to continue

In Configure SAML:

Add https://idp.xaa.dev/saml-resource/acs for Single sign-on URL
Add https://idp.xaa.dev/saml-resource/metadata for Audience URI (SP Entity ID)
Name ID format: select EmailAddress
Application username: select Email
Update application username on: select Create and update
Press Next to continue

⚠️ Note Please note that we’re providing these for setup; they don’t constitute a working SSO connection to the resource app. Also, don’t assume the NameID is an email address; it is whatever the customer’s SSO emits. Your matching set must remain consistent across your deployment.

Press Finish to create the Okta SAML 2.0 application.

After creating the app, you’ll see more configuration options for your Okta SAML 2.0 app. You’ll make changes in the resource server tab.

Resource Server extra configuration

Navigate to the Resource Server tab and make the following configuration changes:

Select Enable XAA
Issuer URL: Add this value to your Issuer URL: https://auth.resource.xaa.dev

Assignments configuration

Navigate to the Assignments tab and make the following configuration changes:

Select Assign > Assign to People
Search for your test user and select Assign
Press Save and Go Back, then select Done

The next step is to set up xaa.dev for the resource app.

Go to Test your requesting app Add your IdP issuer URL as your Okta Integrator account ID (i.e., https://your-okta-domain.okta.com) Put your email into the Test user identifier example, name1234…@okta.com Finally, select My ID-JAG is SAML-derived and add your SAML IdP entityID from the requesting app you created under the Sign On tab > SAML Setup > View SAML setup instructions, open the saml-doc file, and find the Identity Provider Issuer value (i.e., http://www.okta.com/) After all values are entered, click on the **Register**

Register and configure the AI Agent in Okta

With your Okta SAML 2.0 requesting app and the resource app configured, register a new AI Agent in Okta. The AI Agent configuration defines the relationship between the Okta SAML 2.0-requesting app you have and the resource application, which in this case is xaa.dev. You’ll configure credentials, add your requesting app as a delegated caller, and connect the resource app as a Resource Connection.

In the Okta Admin Console:

Navigate to Directory > AI Agents
Select Register AI Agent > Register Manually
Enter a Name, e.g., “Agent”
Select Register

Select the AI Agent you just created to open its configuration. Configure the agent across the following tabs:

On the Owners tab
1. Select Assign individual owners
2. Search for and add yourself as an owner
3. Press Save
On the Credentials tab (select the agent you’ve just created to see this tab)
1. Copy the AI agent ID and add the value as the Client ID for your requesting app.
2. Back in Okta, select the Add Public Key, and then press Generate new key. Okta generates a key pair and displays the private key. Under PEM, press Copy to clipboard, then store the key securely on your end. You’ll paste this private key into the Private key (PKCS8 PEM or private JWK) field in your requesting app, then save.
Also copy the kid and add it back to your requesting app
On the Delegations tab
1. Select Add Caller
2. Search for the newly created Okta SAML requesting app
3. Select Add Caller to confirm
On the Resource Connections tab
1. Select Add Resource Connection. Under the Resource section, select Application as the resource type.
  1. Under the Application section, choose your App configured for AI Agent access instance as the Resource app. (In this case, it should be the “Resources App”) from the dropdown menu and paste the Client ID from xaa.dev. (It should look something similar to byora...)
2. Under Scope Condition, select Allow all
3. Select Add to confirm

The final step is to activate the AI agent. Go to Actions and select Activate

Once the AI Agent is active, the configuration is complete. All checkmarks on the agent configuration page must be green.

Test the SAML 2.0 app

At this stage, you are all set to run the requesting app and verify the complete XAA flow it is supposed to perform.

Validate the XAA connection end-to-end

Once the flow is complete in the SAML 2.0 application, return to xaa.dev. In the Live verification tab, a green Conformance passed panel appears. This confirms all steps:

Auth Server Accepted your ID-JAG
Access token was issued
Resource Server accepted your access token
API call to the /api/todos/ was a success.

At this stage, the JSON conformance log will have the complete details of the XAA flow.

Learn more about Cross App Access, SAML, and OAuth 2.0

If this guide helped you implement Cross App Access with SAML, explore these resources:

📘 Cross App Access Documentation: Official guides for configuring and managing Cross App Access in production
🎙️ Developer Podcast on MCP and Cross App Access: Hear the backstory, use cases, and why this matters for developers
📋 How to Build and List Secure Cross App Access (XAA) Connections on Okta Integration Network (OIN)

Identity 101:

Build a Secure C# MCP App with Cross App Access (XAA)

Thu, 16 Jul 2026 00:00:00 -0500

A few years ago, getting a user signed in to an application or multiple applications with Single Sign-On (SSO) was enough; OpenID Connect (OIDC) handled the login, JWTs carried the claims, and Proof Key for Code Exchange (PKCE) made it secure. Today, with evolving AI, agents act on behalf of users and seek multiple accesses across different resources to execute a task. And that is when you’ll hit the gap.

The user has an identity, but the downstream service—like a Model Context Protocol (MCP) server, an API, or an agent tool has no way to trust it: the ID Token that proves the user’s identity for your app, not for that service. You need a way to take that identity and have it trusted further down the chain, in line with the org’s policy, without asking the user to log in again.

Cross App Access (XAA) solves exactly that. The user authenticates once. The Identity Provider (IdP) evaluates the enterprise policy and issues a signed Identity Assertion. The downstream service exchanges that assertion for a scoped Bearer token.

In this post, we’ll explore how Cross App Access (XAA) closes the trust gap, test the flow using an XAA playground, and implement a secure MCP client in just a few lines of C# using our dedicated SDK.

Table of Contents

What is Cross App Access (XAA)?
Implementing XAA with the C# MCP SDK
Testing your C# MCP app with xaa.dev
Run your C# MCP app with xaa.dev
Learn More About Secure AI Agent Development with C# and MCP

What is Cross App Access (XAA)?

Before we start implementing and building the application, it is important to understand the mechanics of Cross App Access (XAA). At its core, XAA is an open standard that securely enables AI agents to act on behalf of a user and communicate with downstream applications without requiring constant, manual user consent.

While the flow is sophisticated, it relies on two standard interactions:

RFC 8693 (Token Exchange): The requesting app exchanges an OIDC ID token for a JWT Authorization Grant (JAG) at the enterprise Identity Provider.
RFC 7523 (JWT Bearer Grant): The app presents this JAG to the MCP authorization server to receive a scoped access token for the resource.

The diagram below gives a complete flow for XAA and token exchanges.

You can find a complete flow diagram and explanation of XAA in the “Integrate Your Enterprise AI Tools with Cross App Access” blog.

In the next steps, let us understand how to implement the 4 steps of XAA using the MCP software development kit (SDK).

Implementing XAA with the C# MCP SDK

Building this manually would require you to manage complex cryptographic handshakes. Instead, we’ll use the C# MCP SDK; more details are available in the official GitHub repository. The C# MCP SDK’s IdentityAssertionGrantProvider handles all the heavy lifting, abstracting these RFCs into a clean, developer-friendly interface that lets you focus on your agent logic rather than the authentication plumbing. Let us implement that step by step.

Building the OIDC flow

ASP.NET Core has a built-in OIDC middleware that handles the full authentication flow, including PKCE. Since the package handles the implementation, all we have to do is configure our values.

builder.Services
    .AddAuthentication()
    .AddCookie(o => { o.Cookie.Name = "xaa.auth"; })
    .AddOpenIdConnect(o =>
    {
        o.Authority    = config["Xaa:IdpBaseUrl"];
        o.ClientId     = config["Xaa:ClientId"];
        o.ResponseType = "code";
        o.UsePkce      = true;
        o.SaveTokens   = true; // ID Token persisted into the auth cookie
        o.MapInboundClaims = false;
        o.Scope.Add("openid");
        o.Scope.Add("email");
    });

An important thing to note here is that MapInboundClaims = false, which stops ASP.NET Core from remapping standard OIDC claim names to legacy WS-Federation names, keeping the token payload clean and predictable downstream.

Automate XAA token exchange with C# SDK

This step marks the start of the XAA flow. With the SDK, instead of the user directly authorizing the MCP client, the app performs a two-hop token upgrade on the user’s behalf, and the MCP C# SDK’s IdentityAssertionGrantProvider encapsulates both exchanges.

The application presents the user’s ID token to the IdP and represents the user’s identity to the MCP server. The IdP responds with an ID-JAG, a short-lived token that grants access to the resource server. You then exchange this ID-JAG for an access token to access the server.

var provider = new IdentityAssertionGrantProvider(
    new IdentityAssertionGrantProviderOptions
    {
        ClientId         = config["Xaa:McpClientId"]!,
        ClientSecret     = config["Xaa:McpClientSecret"],
        IdpTokenEndpoint = $"{config["Xaa:IdpBaseUrl"]}/token",
        IdpClientId      = config["Xaa:ClientId"]!,
        IdpClientSecret  = config["Xaa:ClientSecret"],
        Scope            = "todos.read mcp.access",

        // Called by the SDK when it needs the current user's ID Token
        IdTokenCallback = (_, _) => Task.FromResult(idToken)
    },
    httpClient);

var result = await provider.GetAccessTokenAsync(
    resourceUrl:           new Uri(config["Xaa:McpServerUrl"]!),
    authorizationServerUrl: new Uri(config["Xaa:AuthServerUrl"]!));

var accessToken = result.AccessToken;

With the IdTokenCallback, the provider retrieves the user’s ID Token from the session.

Connect the MCP client to the server

After the exchanges, this is the final part, where the client can now access the MCP server and use the resource data. The HTTP-based servers handle session negotiation and message framing.

//Set up the transport with the exchanged access token
var transport = new HttpClientTransport(new HttpClientTransportOptions
{
    Endpoint          = new Uri(config["Xaa:McpServerUrl"]!),
    TransportMode     = HttpTransportMode.StreamableHttp,
    AdditionalHeaders = new Dictionary<string, string>
    {
        ["Authorization"] = $"Bearer {accessToken}"
    }
});

// Initialize the MCP client
await using var client = await McpClient.CreateAsync(transport);

McpClient.CreateAsync performs the MCP initialization handshake, exchanging the protocol version and capabilities with the server before making any resource request. From here on, interacting with the server is straightforward.

var resources = await client.ListResourcesAsync(); //lists all the available URIs
var result    = await client.ReadResourceAsync("todo0://todos");

var raw = string.Join("",
    result.Contents
          .OfType<TextResourceContents>()
          .Select(c => c.Text ?? ""));

This app uses todo0://todos to fetch from the xaa.dev resource server. The complete sample code for the app is available in the linked GitHub repository.

Testing your C# MCP app with xaa.dev

Now that we’ve stepped through the XAA flow, it’s time to test it. xaa.dev is a testing playground. It provides a standardized, functional environment that lets you verify your end-to-end flow immediately and serves as the bridge between your app and the downstream resource.

To test out the application using the xaa.dev platform, follow the steps below to get the app registered as the requester app:

Go to xaa.dev and select the Register, test, and manage your requesting app tab, then select Continue with your app.
Enter your email and click on Continue and Register New App.
Enter the Redirect URI and Post-logout URI as below.
Click on the Add Resource section and select ToDo MCP Server.
Click on Register App, and your app is now registered as a requester app in the XAA flow.

You should have your connections set up like in the screenshot below.

In this example, the C# app is a requester app that fetches the to-do list from the Todo app and analyzes the tasks fetched.

Run your C# MCP app with xaa.dev

At this point, you should have your application ready, running on port 5000, and connected to the XAA sample resource app. If not, you can clone the repo from the GitHub repository and add the following environment variables to the appsettings.json file:

git clone https://github.com/oktadev/csharp-mcp-sdk-example.git
cd xaa-csharp-mcp-sdk-example

{
  "Xaa": {
    "ClientId":        "<your-client-id>",
    "ClientSecret":    "<your-client-secret>",
    "IdpBaseUrl":      "https://idp.xaa.dev",

    "McpClientId":     "<your-mcp-client-id>",
    "McpClientSecret": "<your-mcp-client-secret>",

    "AuthServerUrl":   "https://auth.resource.xaa.dev",
    "McpServerUrl":    "https://mcp.xaa.dev/mcp",

    "RedirectUri":     "http://localhost:5000/callback"
  },
  "Logging": {
    "LogLevel": { "Default": "Information", "Microsoft.AspNetCore": "Warning" }
  },
  "AllowedHosts": "*"
}

Make sure to copy the correct client ID and secrets from xaa.dev. Once done, run the app.

dotnet run

Go to http://localhost:5000/, and you should see the app.

Sign in to the app using a test email and provide a random verification code as below. Once you sign in, the XAA playground handles the login request; you can verify this by checking the URL on your screen.

Once done, you should see the analyzer app running the XAA flow, displaying all details and analyzing all To-Do tasks.

The MCP SDK and XAA simplify building and testing cross app access.

Learn More About Secure AI Agent Development with C# and MCP

What you’ve seen here is the full XAA flow, starting from a user signing in with SSO to an AI agent securely fetching data from an MCP server running end-to-end in under 50 lines of C#.

The XAA playground (xaa.dev) makes this tangible without any infrastructure overhead. The IdP, the Auth Server, the MCP resource server — it’s all there, ready for you to register your app, drop in the credentials, and watch the token exchanges happen in real time. That’s the fastest path from concept to a working implementation.

If you wish to read further:

Test the full source for this demo in the GitHub repository
Register your own app and explore the XAA playground at xaa.dev
Read the deep dive on how XAA closes the enterprise trust gap in Integrate Your Enterprise AI Tools with Cross App Access

As AI agents take on more complex, multi-step tasks across organizational boundaries, XAA is the secure solution that enables this without compromising security or user experience. Now you have the tools to build it.

Remember to follow us on X and subscribe to our YouTube channel for more exciting content. We also want to hear from you about the topics you’d like to see and any questions you may have. Leave us a comment below!

Introducing Okta Journeys: A Better Way for Developers to Learn Identity

Tue, 07 Jul 2026 00:00:00 -0500

Learning identity management is hard enough. Navigating Okta’s documentation to build something shouldn’t be. If you’ve ever lost an afternoon stitching together how-to guides, product docs, and scattered blog posts just to figure out where to start, you’re not alone – and we’ve heard you, loudly and repeatedly.

Today, we’re excited to announce the official launch of Journeys: a new way to navigate Okta documentation built around the tasks you’re actually trying to accomplish.

What are Okta Journeys for developers?

A Journey is a curated, expert-driven, end-to-end guide built around a small-to-medium-sized development project. Rather than sending you to find a single document and piece the rest together yourself, each Journey walks you through the entire project, from foundational concepts to completion.

Journeys address the most frequent questions we’ve heard from developers. Every Journey includes both brand-new material and revised content to ensure that what you’re reading is accurate, up to date, and genuinely useful.

Each Journey organizes content into three main sections.

Learn identity foundations

Before you write a single line of code, it helps to know the terrain. The Learn section anchors the broad “identity” concept, covering foundational knowledge including Okta features, software development kits (SDKs), and application programming interfaces (APIs) relevant to your task. Whether you’re new to Okta or just unfamiliar with a specific area, this section gives you the vocabulary and mental model you need to make informed decisions. It ensures you’re not just following steps, but truly understanding the technology and concepts underlying your project.

Plan your customer identity implementation

Good implementations start with good planning. The Plan section walks you through the key decision points to consider before you begin – from the pros and cons of migration strategies and deployment models to configuration options, rate limits, and key performance indicators (KPIs). These are all common concerns from the field. Decisions made here shape everything that follows, so you won’t discover them for the first time mid-build.

Build and implement identity solutions

This is where everything comes together. The Build section presents a carefully curated collection of resources, organized to guide you through your project from start to finish. No more hunting across technical content channels to find the correct how-to guide, configuration advice, Knowledge Base (KB) article, blog post, API endpoint details, or videos. Everything you need is in one place, in the right order.

Every Journey covers the Okta-recommended approach and adds common alternatives when practical, because we know one size doesn’t always fit all.

Six Okta Journeys available now

The first six Journeys are live today, targeting Okta Customer Identity (OCI) builders developing and securing customer-facing portals. If you’re working on user authentication, registration, company branding, or user management, these Journeys are for you.

Explore Journeys

What’s next: Okta for AI agents and more

This is just the beginning. We’re already building new Journeys to tackle high-impact, emerging scenarios, including:

Okta for AI Agents: Detect, identify, manage, register, and govern your AI agents.
Building for the Okta Integration Network (OIN): Journeys for developers building different types of integrations for the Okta Integration Network.
Classic Engine to Okta Identity Engine Migration: Update your org to Okta Identity Engine and remove the Classic Engine-specific code from your apps.

We are committed to continuously expanding this library so that, no matter your development goal, you have a clear, expert-guided path to success.

Tell us what you think

These Journeys will fundamentally improve your development experience. Explore them, share your feedback, and let us know what Journeys you’d like to see next. Use the feedback tab on the Journey page, reach out to us on the Okta Developer Forums, or find us on socials.

Happy building.

Remember to follow us on X and subscribe to our YouTube channel and LinkedInfor more exciting content. We also want to hear from you about the topics you’d like to see and any questions you may have. Leave us a comment below!

How to Build and List Secure Cross App Access (XAA) Connections on Okta Integration Network (OIN)

Mon, 06 Jul 2026 00:00:00 -0500

AI agents have evolved from novelties into active participants in enterprise workflows. They now operate across systems, reading data, executing actions, and calling APIs on behalf of users.

This evolution creates a new security hurdle for enterprises. Software and agents need to connect without relying on static API keys, scattered OAuth consent, or unmanaged integrations. Cross App Access (XAA) addresses this by bringing these connections under the enterprise identity layer.

Table of Contents

What is Cross App Access (XAA)?
Why Cross App Access (XAA) matters for ISVs and their customers
Prerequisites for supporting Cross App Access (XAA) in your app
Implementation and testing guide for Cross App Access (XAA) with Okta as IdP
Getting listed in the Okta Integration Network (OIN)
- XAA enablement questionnaire
- What happens next after you submit your OIN and XAA request?
Need help with your Cross App Access (XAA) submission?
Learn more about Cross App Access and the Okta Integration Network

What is Cross App Access (XAA)?

Cross App Access (XAA) is an identity framework that secures token-based communication when software or AI agents request data from external ecosystems, and those apps have an established trust relationship with an Identity Provider (IdP). It replaces insecure, long-lived API keys or hardcoded secrets with a pattern for real-time identity propagation between different application vendors.

Watch the video below to see Cross App Access (XAA) in action:

A concrete way to think about it: consider an employee using an AI assistant to prepare for a meeting. The assistant might need to pull tasks from one application, notes from another, and account details from a third. Without XAA, every connection might require separate user permissions, distinct API keys, or custom administrative work.

XAA allows enterprises to centrally determine which apps connect, which scopes they request, and which users gain access. This streamlines the user experience while giving the enterprise the control it requires.

Why Cross App Access (XAA) matters for ISVs and their customers

Every time an AI agent or application accesses another system without a proper identity handshake, customers face security and compliance risks. XAA eliminates this gap, providing IT teams with the visibility and audit trails they need to govern cross-app identity flows.

For ISVs, XAA adoption simplifies the integration process in enterprise environments where security and visibility remain top priorities. It demonstrates trust to buyers, showing that your application fits into a secure, modern ecosystem. As enterprises increase their expectations for secure integrations, XAA readiness becomes a powerful competitive differentiator.

At a high level, XAA involves three distinct roles:

Requesting app: the requesting app acts on behalf of the user but does not mint the identity assertion itself. Instead, it receives an ID token or Security Assertion Markup Language (SAML) assertion from the identity provider and exchanges that assertion for an Identity Assertion Authorization Grant (ID-JAG), a JSON Web Token (JWT).
Resource app: the resource app owns the API or data. It validates the incoming ID-JAG and issues a scoped access token if the request is valid.
Identity Provider: authenticates the subject, evaluates access policies, and generates the necessary ID-JAG. Okta fills this role in an XAA deployment.

Prerequisites for supporting Cross App Access (XAA) in your app

Before you start building, ensure you have these prerequisites in place:

Defined app role: determine if your app will function as a requesting app, a resource app, or both.
Authorization server support: if your app acts as a resource app, your authorization server must validate the ID-JAG and issue a scoped access token for the protected resource.
Scopes and protected resources: if you are building a resource app, clearly define the APIs and scopes available to requesting apps.
Okta Integrator Free Plan org: use this org to build, test, and submit your integration. You can register for a new account. After signing up, email developers@okta.com to enable the XAA feature for your org.
Single Sign-On (SSO) integration: XAA relies on the trust your existing SSO already establishes. Ensure your app supports OpenID Connect (OIDC) or SAML SSO with Okta.
Tested workflows: you must demonstrate that XAA works with Okta as the IdP before requesting XAA enablement for your Okta Integration Network (OIN) integration.

Implementation and testing guide for Cross App Access (XAA) with Okta as IdP

To begin development, select the guide corresponding to your application’s authentication protocol:

If your resource app uses SAML for SSO, follow our SAML resource app implementation guide.
If your requesting app uses SAML for SSO, follow our SAML requesting app implementation guide.
If your app uses OIDC for SSO, refer to the OIDC implementation guide.

To verify your configuration, demonstrate a successful token exchange:

Requesting apps: provide evidence that you successfully obtained an ID token via OIDC SSO and used it to mint an ID-JAG.
Resource apps: show that your app received an ID-JAG and successfully exchanged it for a scoped access token.

Completing these tests is a hard requirement for approval; please ensure they are successful before submitting your integration.

Getting listed in the Okta Integration Network (OIN)

Listing your integration on the Okta Integration Network (OIN) helps customers discover and trust it. Because XAA relies on trust that your existing single sign-on (SSO) configuration already establishes, you must list an OIDC or SAML SSO integration on the OIN before proceeding.

If your app is not yet listed, prioritize that submission. Submit your SSO app through the OIN Wizard. This Okta Integration Network guide walks you through everything you need to get your integration listed, from app metadata to SSO configuration. Once you submit your SSO app for review, you can begin the XAA enablement request in parallel.

XAA submissions currently require a manual step: you need to contact Okta directly to indicate that your submission includes XAA support. When your app successfully passes token exchange tests, email the Okta team at oin@okta.com to request XAA enablement. To speed up the review and avoid additional rounds of configuration, include the completed questionnaire below in your email.

Use this subject line: Request to enable XAA support for <App Name> on OIN

XAA enablement questionnaire

General app details:

App Name:
Okta Integrator Org domain:
SSO Mode: OIDC / SAML
XAA App Role: Requesting app / Resource app / Both
Existing OIN App Link, if already published
Submission Type: new OIN submission / update to an existing OIN app

Requesting app details: fill this out if your app acts as a requesting app.

Resource Registration Pairs: for each resource app you connect with, provide:
- Resource app name
- Authorization Server Issuer URL
- Registered Client ID
Supported Scopes: list the scopes your app requests from resource apps.
Client ID Metadata Documents (CIMD) Support:
- If yes, please provide the CIMD URL
- No
- Planned future support

Resource app details: fill this out if your app acts as a resource app.

Global Issuer URL: the endpoint that processes ID-JAG token exchange requests
Protected Resource Identifiers: URLs of the APIs your app exposes (e.g., https://api.yourdomain.com/v1)
Supported OAuth Scopes: scopes allowed for XAA token exchange (e.g., openid, read, write)
CIMD Support:
- If yes, please provide the CIMD URL
- No
- Planned future support
Well-Known Host Endpoints: specify whether you host either of the following:
- .well-known/oauth-authorization-server
- .well-known/oauth-protected-resources

Testing details:

If you’re a requesting app: confirm that you generated successful token exchange logs. The Okta operations team can verify these via internal telemetry parameters. To help the team validate quickly, also include:
- Test org
- App name
- Test user or test account used
- Resource app tested against
- Scopes requested
If you’re a resource app: attach a screenshot or a short video showing successful ID-JAG validation and scoped access token exchange logs directly from your authorization server. These cannot be verified externally, so the evidence needs to come from you. Please include:
- Resource endpoint tested
- Scopes granted
- Token exchange result

What happens next after you submit your OIN and XAA request?

Once you submit your request, the Okta team reviews your SSO submission, XAA metadata, and testing evidence. If your app is already on the OIN, we will update the existing listing after approval. For new integrations, we complete the standard SSO review before publishing your app with XAA support. If the team needs further clarification or additional testing evidence, we will contact you directly.

Need help with your Cross App Access (XAA) submission?

Please reach out to developers@okta.com for help. You can also find answers and connect with peers in our developer community.

XAA advances how apps and agents interact securely. By supporting this standard and listing your integration on the OIN, you help enterprise customers adopt AI-driven automation with better governance, stronger identity control, and increased confidence.

Learn more about Cross App Access and the Okta Integration Network

If this guide helped you plan your OIN and XAA submission, explore these resources next:

📘 Cross App Access documentation: official guides for configuring and managing Cross App Access in production.
📄 Okta Integration Network documentation: everything you need to get your SSO integration listed on the OIN.
🔐 Enabling Cross App Access for SAML-Based Resource Apps: the implementation guide for SAML SSO resource apps.
🔐 Enable Your SAML Requesting App for Cross App Access: the implementation guide for SAML SSO requesting apps.
🔑 Build secure agent-to-app connections with Cross App Access (XAA): the implementation guide for OIDC SSO apps.
🎙️ Developer podcast on MCP and Cross App Access: hear the backstory, use cases, and why this matters for developers.

Enabling Cross App Access for SAML-Based Resource Apps

Fri, 03 Jul 2026 00:00:00 -0500

If you currently federate enterprise customers using Security Assertion Markup Language (SAML) and want to allow applications to access your API without migrating to OpenID Connect (OIDC), this Cross App Access (XAA) guide is for you.

The Identity Assertion Authorization Grant specification, the basis of XAA, was originally designed with OIDC in mind. To use it in SAML applications, you must accommodate specific security and uniqueness requirements. This guide details what you need to support and how to verify SAML-derived claims at your resource authorization server.

Table of Contents

How XAA in SAML works
Analyzing the ID-JAG claims
XAA implementation checklist for SAML-federated applications
Making cross-application requests from your SAML app securely
Configure your XAA SAML App in Okta
Verify your Okta XAA setup on xaa.dev
Takeaways for implementors who have both OIDC and SAML apps
Learn more about Cross App Access, SAML, and OAuth 2.0

How XAA in SAML works

When an agent (like one running in Claude) needs API access, it presents an Identity Assertion Authorization Grant (ID-JAG). The ID-JAG is a short-lived JSON Web Token (JWT) issued by the customer’s Identity Provider (IdP) for your authorization server. Your resource server accepts the token, identifies the user, and issues your own access token, all while leaving the customer’s existing SAML integration untouched.

The sequence diagram shown below describes the SAML XAA flow. Notice that the SAML SSO flow stays the same; the only change is the section highlighted with the comment “Your Resource Authorization Server (AS): redeem and resolve”. You’ll make a POST request to your resource’s authorization server with the ID-JAG, resolve the NameID to return an access token that you’ll use for resource requests.

⚠️ Note

You are not processing SAML here. The only artifact crossing from the IdP to your domain is the ID-JAG. All SAML-related tasks, such as SSO, assertion handling, and subject derivation, happen upstream. Your responsibility is to validate the ID-JAG, redeem it for an access token, and resolve the user from the claims.

Analyzing the ID-JAG claims

When you decode the ID-JAG, you’ll see claims in the header and payload that impact how you process the access request:

// header
{
  "typ": "oauth-id-jag+jwt",
  ...
}

// payload
{
  "iss": "https://atko.okta.com",
  "sub": "00u1a2b3c4D5e6F7g8h9",
  "sub_id": {
    "format": "saml-nameid",
    "issuer": "http://www.okta.com/exk1fcia8zMValiD0h8",
    "nameid": "alice@atko.com",
    "nameid_format": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
    "sp_name_qualifier": "https://chat.example/saml/metadata"
  },
  "aud": "https://auth.chat.example",
  "client_id": "0oa8claudeMcpAtYourAS",
  "email": "alice@atko.com",
  "scope": "chat:read chat:write",
  "jti": "id-jag-7f3c9a21b8",
  ...
}

Focus on these key claims noted in the decoded ID-JAG payload:

sub_id: This is the primary field for user resolution
aud: Indicates the endpoint URL for the resource authorization server
client_id: This is the client’s ID at your resource authorization server, which might differ from its ID at the IdP
email: Recommended by the specification for just-in-time provisioning if the user has not yet signed in
jti: This is the unique ID for the ID-JAG JWT that prevents replay attacks within the validity window

XAA implementation checklist for SAML-federated applications

To fully support Cross App Access, implement these five steps in sequence:

How XAA in SAML works
Analyzing the ID-JAG claims
XAA implementation checklist for SAML-federated applications
Making cross-application requests from your SAML app securely
Configure your XAA SAML App in Okta
Verify your Okta XAA setup on xaa.dev
Takeaways for implementors who have both OIDC and SAML apps
Learn more about Cross App Access, SAML, and OAuth 2.0

Mapping user identity in the SAML `NameID` attribute

Unlike OIDC apps, which typically resolve users from the sub claim, SAML-federated apps do not have a corresponding sub claim in their SAML assertion. Consequently, they often lack a direct way to map users without using the sub_id field.

You must compare every member of the saml-nameid identifier used as a subject key for a given SAML issuer. Do not resolve based on the NameID alone unless your local policy permits it.

The NameID field alone doesn’t uniquely identify a user, since two organizations could each have an employee named Alex Chen. This problem is analogous to resolving user uniqueness in multi-tenant applications.

Resolve on NameID + sp_name_qualifier together; the combination of both fields provides the unique user identity required.

⚠️ Note

Don’t assume the NameID is an email address; it is whatever the customer’s SSO emits. Your matching set must remain consistent across your deployment.

Validating the ID-JAG and resolving the user

The client posts the ID-JAG as a JWT authorization grant and authenticates with its credentials at your server. Below is an example HTTP request for requesting an access_token

POST /oauth2/v1/token HTTP/1.1
Host: chat.example
Authorization: Basic <base64(client_id:client_secret)>
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&assertion=eyJ0eXAiOiJvYXV0aC1pZC1qYWcrand0...

Before processing, you must bind the ID-JAG’s iss to a registered SAML connection to prevent forgery.

If you verify the signature before checking the issuer binding, an attacker could potentially create their own IdP, sign a token, and use your customer’s SAML issuer as the sub_id.

Always resolve the connection from the iss first, then verify the signature against that connection’s key. You’ll compare this using the JSON Web Key Set (JWKS) metadata.

Below is the pseudocode for implementing the validation and resolving a user:

connections = {
  "https://atko.okta.com": {
    jwks:            "https://atko.okta.com/oauth2/v1/keys",
    samlIssuer:      "http://www.okta.com/exk1fcia8zMValiD0h8",
    spNameQualifier: "https://chat.example/saml/metadata",
  },
}

redeem(idJag, authenticatedClient):
    // 1. Bind iss to a connection before trusting the signature.
    iss  = unverified_issuer(idJag)
    conn = connections[iss]
    if conn is none: reject "invalid_grant"

    // 2. Verify signature against the specific issuers JWKS.
    payload = verify_jwt(idJag, jwks = conn.jwks)
    if payload is invalid: reject "invalid_grant"

    // 3-5. Perform remaining checks.
    require payload.typ       == "oauth-id-jag+jwt"
    require payload.aud       == "resource_authorization_server_url"
    require payload.client_id == authenticatedClient.id

    user  = resolveSamlSubject(payload.sub_id, conn)
    scope = applyScopePolicy(user, payload.scope)
    return issueAccessToken(user, scope)

resolveSamlSubject(subId, conn):
    require subId and subId.format == "saml-nameid"
    require subId.issuer == conn.samlIssuer
    require subId.sp_name_qualifier == conn.spNameQualifier

    user = lookup_user_by_saml_nameid(subId.issuer, subId.nameid, subId.sp_name_qualifier)
    if user is none: reject "invalid_grant"
    return user

Issuing the access token

Once you resolve the user, issue an access_token scoped according to your local policy. Below is an example of an access_token returned after successfully validating the ID-JAG and resolving the user.

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store

{
  "token_type": "Bearer",
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "expires_in": 86400,
  "scope": "chat:read chat:write"
}

⚠️ Note

Do not issue a refresh token. If your authorization server issues a refresh token, the client has durable access to your resource server, and the IdP cannot revoke access.

The ID-JAG replaces the need for a refresh token. On access token expiry, the client resubmits the same ID-JAG to your token endpoint, and you mint a new access token against it. Only once the ID-JAG itself expires does the client request a new ID-JAG from the IdP using its own refresh token.

Updating authorization server metadata

Clients locate your XAA support via your authorization server metadata (/.well-known/oauth-authorization-server). Ensure you include the supported fields:

{
  "issuer": "https://chat.example",
  "token_endpoint": "https://auth.chat.example/oauth2/v1/token",
  "grant_types_supported": [
    "urn:ietf:params:oauth:grant-type:jwt-bearer"
  ],
  "authorization_grant_profiles_supported": [
    "urn:ietf:params:oauth:grant-profile:id-jag"
  ]
}

Making cross-application requests from your SAML app securely

With these five steps complete, your SAML application is configured for Cross App Access. Agents can now authorize requests against your API while maintaining your existing production federation, eliminating the need for protocol migration.

You can now use Okta to make cross-application requests with your SAML app.

Configure your XAA SAML App in Okta

Let’s test your SAML application in Okta. Before you begin, you’ll need some configuration values from the xaa.dev site.

Navigate to https://xaa.dev. Under the heading “Ready to bring your own actors?” select the Resource App option. You will now select Test it against a hosted Requesting App option. Now select the SAML option. Finally, select the Take me there > button. You may be prompted for an email address. Enter any valid formatted email, then press continue. You’ll need two values: the Single Sign-On URL (Assertion Consumer Service, or ACS) URL and the Audience URI (SP Entity ID).

Keep this site open in your browser; you’ll return to it throughout the setup.

Create the SAML 2.0 resource app in Okta

Before you begin this step, you’ll need an Okta Integrator Free Plan account. Sign up for a new account to test out the XAA features.

Cross App Access is an early access feature in Okta. New Integrator Free Plan account types include XAA support. If you have a paid Okta org plan and the following options are missing, contact your representative.

Enable AI Agent Identity Assertion:

Navigate to Settings > Features > Early Access
Find AI Agent Identity Assertion and Agent to Agent Connections, and enable both

You’ll need an Okta application representing your requesting and resource apps.

If you don’t have Okta SAML 2.0 applications representing your requesting and resource apps, you’ll need to create them. Create Okta SAML 2.0 applications by following these instructions.

Navigate to Applications > Applications.

Select Create App Integration. In the Create a new app integration modal, select SAML 2.0 and press Next.

In General Settings:

App name: Enter a descriptive name for the app, for example, “Resource App”
Press Next to continue

In Configure SAML:

Single sign-on URL: Use the ACS URL of your resource app, e.g., “https://idp.xaa.dev/saml-requester/acs”
Audience URI (SP Entity ID): Use the SP Entity of your requestor or resource app, e.g., “https://idp.xaa.dev/saml-requester/metadata”
Name ID format: select EmailAddress
Application username: select Email
Update application username on: select Create and update
Press Next to continue

Press Finish to create the Okta SAML 2.0 application.

After creating the app, you’ll see more configuration options for your Okta SAML 2.0 app. You’ll make changes in more than one tab.

Sign On configuration

Select the Sign On tab. Locate the Metadata URL field and press Copy to save it to your clipboard. Paste this URL to the SAML app metadata URL field in xaa.dev and save.

Your SSO endpoint and Token endpoint are automatically configured.

Assignments configuration

Navigate to the Assignments tab and make the following configuration changes:

Select Assign > Assign to People
Search for your test user and select Assign
Press Save and Go Back, then select Done

Resource Server extra configuration

Navigate to the Resource Server tab and make the following configuration changes:

Select Enable XAA
Issuer URL: Use your resource authorization server issuer URL. This value becomes the aud claim in the ID-JAG and cannot change without deleting and resetting the connection.

Create a SAML 2.0 requester app for testing

Return to xaa.dev. This is where you will provide these two values: the Single Sign-On URL (the Assertion Consumer Service (ACS) URL) and the Audience URI (SP Entity ID).

Create another Okta SAML 2.0 application in the Okta Admin screen by following these instructions.

Navigate to Applications > Applications.

Select Create App Integration. In the Create a new app integration modal, select SAML 2.0 and press Next.

In General Settings:

App name: Enter a descriptive name for the app, for example, “Requesting App for Testing”
Press Next to continue

In Configure SAML:

Single sign-on URL: Use the ACS URL from xaa.dev, e.g., “https://idp.xaa.dev/saml-requester/acs”
Audience URI (SP Entity ID): Use the SP Entity from xaa.dev, e.g., “https://idp.xaa.dev/saml-requester/metadata”
Name ID format: select EmailAddress
Application username: select Email
Update application username on: select Create and update
Press Next to continue

Press Finish to create the Okta SAML 2.0 application.

After creating the app, you’ll see more configuration options for your Okta SAML 2.0 app. You’ll make changes in more than one tab.

Sign On configuration

Select the Sign On tab. Locate the Metadata URL field and press Copy to save it to your clipboard. You’ll paste this URL to the SAML app metadata URL field in xaa.dev and save.

Your SSO endpoint and Token endpoint are automatically configured.

Assignments configuration

Navigate to the Assignments tab and make the following configuration changes:

Select Assign > Assign to People
Search for your test user and select Assign
Press Save and Go Back, then select Done

Register and configure the AI Agent in Okta

With your Okta SAML 2.0 requesting app configured, register a new AI Agent in Okta. The AI Agent configuration represents the relationship between the Okta SAML 2.0 app you created and your MCP Resource Application. You’ll configure credentials, add your requesting app as a delegated caller, and connect your MCP resource app as a Resource Connection.

In the Okta Admin Console:

Navigate to Directory > AI Agents
Select Register AI Agent > Register Manually
Enter a Name, e.g., “Requesting Agent”
Select Register

Select the AI Agent you just created to open its configuration. Configure the agent across the following tabs:

On the Owners tab
1. Select Assign individual owners
2. Search for and add yourself as an owner
3. Press Save
On the Credentials tab (select on the Requesting Agent to see this tab)
1. Copy the AI agent ID
2. Return to the xaa.dev site to add theAI agent ID value as the Client ID and save
3. Back in Okta, select the Add Public Key, and then press Generate new key. Okta generates a key pair and displays the private key. Under PEM, press Copy to clipboard and store the key safely. You’ll paste this private key into the Private key (PKCS8 PEM or private JWK) field in xaa.dev.
4. Copy and paste the associated KEY ID value and paste it into the kid field at xaa.dev and save.
Back at Okta, on the Delegations tab
1. Select Add Caller
2. Search for the newly created Okta SAML requesting app
3. Select Add Caller to confirm
On the Resource Connections tab
1. Select Add Resource Connection. Under the Resource section, select Application as the resource type.
  1. Under the Application section, choose your Application instance – MCP (Resource App) – from the dropdown menu and paste the Client ID at the Resource Authorization Server.
2. Under Scope Condition, select Allow all
Activate the agent
1. The final step is to activate the AI agent, Go to Actions and select Activate

Once the AI Agent is active, the configuration is complete. All checkmarks on the agent configuration page must be green.

Confirm the AI Agent configuration is complete. All checkmarks on the agent configuration page must be green.

Verify your Okta XAA setup on xaa.dev

Before we get to the next section, make sure you have the resource app URL in the resource authorization issuer (ID-JAG audience). By this point, you’ll have every value from the checklist and your one-time Okta setup in place (AI Agent, credentials, owner, delegation, and resource connection), so we’ll add the values from Okta and the apps to walk through the flow step by step, one button per step.

The screenshot below shows the SAML configuration values step on xaa.dev.

Configure SAML SSO

Press Start SAML login at your IdP and complete the login in the pop-up.

When it closes, the step turns green and shows a ✓ Auto-discovered SSO endpoint, confirming that the tester resolved the real .../sso/saml endpoint from your metadata and returned a signed SAML assertion.

Confirm the SAML Assertion exchange for a refresh token

Press Exchange assertion for refresh token. The tester posts the signed assertion to your IdP’s token endpoint, using private_key_jwt authentication. A 200 means the identity provider accepted the assertion, and you now hold an opaque refresh token.

Verify the refresh token exchange for an ID-JAG token

Press Exchange refresh token for ID-JAG. This action returns a decoded ID-JAG. Take a second to review it: aud should equal your Resource authorization issuer, and sub_id should contain the SAML NameID of the user who logged in. The Resource authorization server then validates this token. A 200 OK indicates that the step succeeded.

Redeem the ID-JAG for an access token at the resource authorization server

Fill in your Resource AS token endpoint
Client ID and client secret of the resource app from the Resource Authorization Server

Press Redeem (grant_type=jwt-bearer). If the request succeeds, you’ll receive a 200 OK response with an access token. Inspect the token in the Token tab to verify that theiss, aud, and scope claims match the values configured in your resource authorization server. This validation confirms that the authorization server accepted the ID-JAG and issued its own access token.

Call the resource API with the access token

Select the request method and enter your API URL (The Authorization: Bearer header is added automatically, but you can add any other headers or a request body as needed), then press Send GET Request. A 200 response from your endpoint is the final proof: your API accepts the access token generated by the ID-JAG exchange.

Prove the XAA connection end-to-end

A green Conformance passed panel appears. Select Export conformance log (JSON) to download the test results. The export includes the signed ID-JAG, the access token returned by your resource authorization server, and the API response.

You can share this file with your IdP as proof that the Cross App Access integration works successfully.

Takeaways for implementors who have both OIDC and SAML apps

If you have already implemented XAA in your OIDC apps, here’s a quick checklist to convert your SAML apps:

The subject comes from sub_id in saml-nameid format, rather than sub
Match on every saml-nameid member (issuer + NameID + sp_name_qualifier), rather than just iss and sub
Everything else, including token issuance rules and redemption checks, remains as is

Learn more about Cross App Access, SAML, and OAuth 2.0

If this guide helped you implement Cross App Access with SAML, explore these resources:

📘 Cross App Access Documentation: Official guides for configuring and managing Cross App Access in production.
🎙️ Developer Podcast on MCP and Cross App Access: Hear the backstory, use cases, and why this matters for developers.
📋 How to Build and List Secure Cross App Access (XAA) Connections on Okta Integration Network (OIN)

Identity 101:

The Builder Revolution: Why We're Shifting to Builder Advocacy

Tue, 30 Jun 2026 00:00:00 -0500

My team has officially changed its name, and it’s one I’ve been excited about for a while.

My team is now Builder Advocacy, and our organization is now Builder Experience (BX). We were previously known as Developer Advocacy and Developer Success, respectively.

On the surface, it might look like a simple rebranding. But it’s not. It’s a recognition of something that’s been happening in our industry for a while and has accelerated dramatically recently with this understanding: the definition of who builds things with technology has fundamentally changed.

The builder revolution is already here

For most of computing history, “developer” meant someone who wrote code; they were someone who knew a language, understood a framework, and could navigate a terminal.

That world has changed.

According to the GitHub Octoverse 2025 report, GitHub now has over 180 million developers, with more than one new developer joining every single second. In 2025 alone, 36 million new developers joined the platform, a 23% year-over-year increase. There are now 4.3 million AI-related repositories on GitHub, nearly double the number in 2023, and monthly contributions to AI projects reached approximately 6 million in August 2025, up 188% year over year. Nearly 80% of new developers on GitHub use GitHub Copilot within their first week.

Meanwhile, the Stack Overflow Developer Survey 2025 found that 84% of respondents are currently using or plan to use AI tools in their development work, up from 76% just a year earlier. Nearly half of all developers now use AI tools daily.

AI is already part of the workflow for the majority of people building technology.

But here’s the part that really matters: AI hasn’t just made developers more productive. It has dramatically expanded who can build in the first place.

A new kind of builder

Think about who else is building today, beyond traditional developers:

The product manager who spins up an AI agent to automate their team’s weekly reporting.
The marketing operations analyst who connects APIs through a workflow tool like Zapier without writing a single line of code.
The IT admin who builds a customer-facing chatbot using a low-code platform in an afternoon.
The entrepreneur who vibe-codes their MVP with the help of a large language model (LLM), deploying something that would have taken a full engineering team six months just five years ago.

These people are builders. They may not call themselves developers. They may not have a degree in computer science or formal education in software. But they are creating real, production-level experiences that real users depend on, and they deserve the same quality of advocacy and support that we’ve historically directed at developers.

HubSpot has begun distinguishing “builders” as a specific user persona: those who manage automations, middleware, and integrations, recognizing that the people building on their platform aren’t always traditional developers. AWS has long referred to its community as “builders,” a term that appears throughout their re:Invent programming, documentation, and community initiatives. Salesforce’s legendary Trailblazer community has expanded to embrace AI builders alongside traditional admins and developers as agentic AI becomes central to their platform. Google took this a step further in April 2026 by launching the Builders Hub through their Developer Program, even moving the URL to builders.google. Google is explicitly designed for “vibe coders, AI builders, and professional developers” alike. These are not coincidences. They are signals of a broader industry shift in how we think about the people who build with our platforms.

What builder advocacy means

With this name change, my team is committing — a commitment to showing up for all three types of builders we serve:

Developers: traditional coders, engineers, and architects who have always been our core audience. They’re not going anywhere, and neither is our dedication to them.
AI Builders: prompt engineers, LLM integrators, AI agent creators, and machine learning (ML) practitioners who are building the next generation of intelligent systems. This community is growing at a pace we’ve never seen before.
Automators: no-code and low-code builders who connect systems, design workflows, and create value without traditional programming. They are increasingly building mission-critical infrastructure, and they deserve advocacy, documentation, and tooling that treats them as first-class citizens.

With these name changes — from Developer Success to Builder Experience (BX), and from Developer Advocacy to Builder Advocacy — our team is saying clearly: We see all of you. We are here for all of you.

AI made its impact. It’s not going away

Some name changes are cosmetic. This one isn’t.

The community building with AI isn’t concentrated in a few zip codes anymore. It is global, diverse, and growing in ways that don’t fit neatly into the old categories.

The Stack Overflow Developer Survey 2025 found that 84% of developers are now using or planning to use AI tools. Among those using AI agents, roughly 70% say agents boosted their productivity and reduced task time. The tools are proving their value in the workflow, not just in the demo.

That’s the community I want to be part of. That’s the community I want to advocate for.

What’s next for builders

This name change is effective today, but it’s really the beginning of a larger journey. Our Builder Experience organization is investing in resources, content, and community programs that serve the full spectrum of builders: from the seasoned backend engineer to the AI tinkerer to the automation-first operator.

And here’s what hasn’t changed. You can still find us where you always have:

For documentation, visit our developer docs
For support, head to our developer forum
For helpful videos, visit our YouTube channel
On social media, follow us on our LinkedIn page

If you build — whatever that means to you — we’re here for you.

Welcome to Builder Advocacy.

How Verifiable Digital Credentials Are Reshaping Trust Architecture

Mon, 29 Jun 2026 00:00:00 -0500

The identity stack is getting a new layer, and it’s already in your users’ pockets. Mobile driver’s licenses are live in dozens of U.S. states. The EU is mandating digital identity wallets for hundreds of millions of citizens. Apple Wallet and Google Wallet already hold government-issued credentials. Yet most development teams are not building for it.

The layer is called Verifiable Digital Credentials. The issuer infrastructure is already live, with wallets deployed and standards stable. The industry’s verifier-side adoption is still catching up, and that’s where we’re focusing our engineering work right now.

For years, when applications needed to verify a user’s age, license, or employment status, the default methods were document uploads, third-party verification APIs, and centralized storage of personally identifiable information (PII). It worked. But it accumulated cost at every step: data your infrastructure had to protect, compliance obligations that grew with every sensitive record, manual review queues that created friction, and third-party vendors holding your users’ identity data on your behalf.

VDCs replace that model. A trusted authority, such as a DMV, a university, or an employer, issues a cryptographically signed credential. The user holds it in a wallet. Your application requests the specific proof it needs. The credential validates itself. You record the outcome and move on. No document stored. No PII beyond what the transaction required. No third party in the middle.

The technical foundation relies on the Issuer-Holder-Verifier trust triangle: the Issuer signs the credential, the Holder stores it in a digital wallet, and the Verifier, your application, requests exactly the proof it needs. This model enables selective disclosure, where a verifier can confirm a person meets an age threshold without ever seeing their date of birth, home address, or a photo of their physical ID. By moving from document collection to claim validation, you eliminate manual review queues and dramatically reduce the personal data your infrastructure is obligated to protect.

This is not an incremental improvement on document uploads. It is a different architecture for how applications establish trust, one in which data collection is scoped to exactly what the transaction requires, and verification outcomes are separable from the identity artifacts that produced them.

The timing matters. The standards are mature. The wallets are deployed at scale. The trust ecosystems are live. What the ecosystem needs now is verifier-side applications that implement these flows well. That gap, between where the issuer infrastructure is and where verifier-side development is, is the opportunity in front of engineering teams right now.

Table of Contents

Authentication proves identity. Credentials prove claims.
The VDC standards stack: What you need to know before you build
Verification is not just a valid signature
Progressing beyond the Digital Credentials API to production VDC verification
Learn more about Verifiable Digital Credentials

Authentication proves identity. Credentials prove claims.

The most important distinction in the VDC space is also the most commonly missed.

Authentication answers one question: is this user the legitimate owner of this account? Verification answers a completely different question: can this person prove a specific attribute about themselves, their age, their license, their employment status, or their eligibility?

These are not the same problem. We have spent the last decade perfecting the art of logging users in (OpenID Connect, passkeys, strong MFA), but stretching your auth layer to carry verification responsibilities it was never designed for produces login flows that collect far more than they need to, and systems that are harder to evolve as both concerns grow independently.

The right architecture keeps them separate: authentication establishes the session, and VDC-based verification handles moments when a higher-trust signal is required.

In practice, those moments cluster around a recognizable set of product checkpoints: age gating for regulated goods, step-up verification before sensitive account actions, professional license checks, workforce credential validation, and high-value transactions. These are the natural insertion points for VDC-based verification. Not a replacement for your auth stack, but an additional layer, deployed precisely where the cost of a trust failure is highest.

The VDC standards stack: What you need to know before you build

VDCs are not a single specification. They are a layered ecosystem of interoperable standards, and understanding each layer is foundational to making good architectural decisions. The stack has three layers.

Credential Formats - defines what the credential is and how selective disclosure works. Two formats matter:

SD-JWT VC - selective disclosure built on JSON Web Tokens (JWTs) and developed in the IETF. This is the natural entry point for web and backend teams already working with JWT-based auth. The claims structure is familiar, and selective disclosure is native to the format. The right choice for enterprise credentials, age gating, employment and license verification.

mdoc (ISO 18013-5/7) - the format behind mobile driver’s licenses and government-issued digital IDs. A more tightly governed interoperability environment, stricter format expectations, and more prescribed wallet behavior. If your use case touches government-issued identity, this is your lane.

Protocols - define how credentials move between issuers, wallets, and verifiers. Two specs from the OpenID for Verifiable Credentials family handle both sides of the lifecycle:

OpenID4VCI governs issuance - how a wallet obtains a credential from an issuer. The issuer-side handshake. OpenID4VP governs presentation - how a wallet delivers proof of a claim to your application. It is credential-format-agnostic, supports redirect-based flows today, and supports the Digital Credentials API for web-native UX, where supported.

The W3C Digital Credentials API - the runtime layer that makes this usable in a browser. Its role is directly analogous to what WebAuthn does for passkeys: it standardizes how browsers invoke credential wallets, provides users proper consent context, and eliminates the custom URL scheme and deep-link hacks that make wallet invocation brittle today.

In simple terms: the Digital Credentials API invokes the wallet, OpenID4VCI and OpenID4VP manage the protocol flow, and SD-JWT VC or mdoc define the credential format. These layers are complementary, not interchangeable.

Verification is not just a valid signature

Verifying digital credentials requires more than cryptographic signature validation. A credential can have a mathematically valid signature and still be unacceptable in your application’s context. What determines acceptability is ecosystem trust.

Two concepts are non-negotiable in any verifier-side implementation:

Trust List - the curated set of issuers and signing keys your verifier accepts as authoritative. Think of it as conceptually equivalent to a browser’s root CA store. If the issuer is not on your trust list, the credential is invalid in your context regardless of signature validity.

Trust Framework - the policy and governance rules defining who can participate in the ecosystem and under what conditions. This is the legal and business contract behind the cryptography.

In the U.S. mDL ecosystem, for example, state DMVs publish their signing keys through the AAMVA Digital Trust Service, which serves as a trust anchor for Issuing Authority Certificate Authorities (IACAs). Your verification flow must integrate with that trust source and handle key rotation as issuers update their infrastructure. Build the trust framework integration as a first-class architectural requirement during implementation.

Progressing beyond the Digital Credentials API to production VDC verification

The browser rollout of native APIs is still progressing. Developers should not architect a flow that requires the Digital Credentials API as a hard dependency today. The most resilient path is to build on redirect-based OpenID4VP as your baseline; it works universally without specific browser dependencies, and then layer in the Digital Credentials API as a progressive enhancement to provide a first-class UX where supported.

The broader trends driving VDC adoption are not speculative. Government credential infrastructure is becoming a dependency layer on which developers can build. Data minimization is shifting from best practice to legal requirement as privacy regulations tighten globally. The auth and verification layers are separating permanently as both mature independently. Managed verification platforms are closing the tooling gap by abstracting away format handling, protocol flows, and trust-source integrations, so teams do not have to build every layer from scratch.

The practical path for engineering teams is incremental. Start with one verification moment in your product where the current approach creates measurable friction or accumulates unnecessary data liability. Define the minimum claim that moment actually requires. Keep it separate from your auth layer. Build something bounded. Learn from it. Expand.

The identity stack is getting a new layer. The developers who understand the formats, protocols, trust model, and browser reality are the ones who will architect what comes next. That window is open now, and the gap between where issuer infrastructure is and where verifier-side development is leaves real ground to gain for teams that move early.

The question for every senior engineer reading this is not whether VDCs are coming. They are already here. The question is whether your architecture is ready to meet them. Explore the VDC platform beta today.

Learn more about Verifiable Digital Credentials

If you’d like to explore the standards and ecosystem behind verifiable digital credentials in more detail, these resources are a good starting point.

Follow us on LinkedIn, Twitter, and subscribe to our YouTube channel to see more content like this. If you have any questions, please comment below!

Okta Developer

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

Build a Flask app with OIDC authentication

Create an app integration in the Okta Admin Console

Enable self-service user registration

Add secure user login to a Flask application with Okta

Create a basic Flask web application

Configure Flask environment variables

Implement the OIDC authentication logic

Initialize the Okta OIDC client

Build Flask routes for OIDC authentication

Run the Flask OAuth web app

Call a protected API with OAuth scoped tokens

Build a protected users API

Extend the Flask app to interact with the resource server

Update the Flask UI to display protected data

Test the protected API integration

Learn more about OAuth and OIDC

Enable Your SAML Requesting App for Cross App Access

How XAA in SAML works

XAA implementation checklist for SAML-federated applications

Request the refresh token

Request the ID-JAG token

Request the access token

Handle token expiration

Making cross-application requests from your SAML app securely

Configure your XAA SAML Requesting App in Okta

Register and configure the AI Agent in Okta

Test the SAML 2.0 app

Validate the XAA connection end-to-end

Learn more about Cross App Access, SAML, and OAuth 2.0

Build a Secure C# MCP App with Cross App Access (XAA)

What is Cross App Access (XAA)?

Implementing XAA with the C# MCP SDK

Building the OIDC flow

Automate XAA token exchange with C# SDK

Connect the MCP client to the server

Testing your C# MCP app with xaa.dev

Run your C# MCP app with xaa.dev

Learn More About Secure AI Agent Development with C# and MCP

Introducing Okta Journeys: A Better Way for Developers to Learn Identity

What are Okta Journeys for developers?

Learn identity foundations

Plan your customer identity implementation

Build and implement identity solutions

Six Okta Journeys available now

What’s next: Okta for AI agents and more

Tell us what you think

How to Build and List Secure Cross App Access (XAA) Connections on Okta Integration Network (OIN)

What is Cross App Access (XAA)?

Why Cross App Access (XAA) matters for ISVs and their customers

Prerequisites for supporting Cross App Access (XAA) in your app

Implementation and testing guide for Cross App Access (XAA) with Okta as IdP

Getting listed in the Okta Integration Network (OIN)

XAA enablement questionnaire

What happens next after you submit your OIN and XAA request?

Need help with your Cross App Access (XAA) submission?

Learn more about Cross App Access and the Okta Integration Network

Enabling Cross App Access for SAML-Based Resource Apps

How XAA in SAML works

Analyzing the ID-JAG claims

XAA implementation checklist for SAML-federated applications

Mapping user identity in the SAML NameID attribute

Validating the ID-JAG and resolving the user

Issuing the access token

Updating authorization server metadata

Making cross-application requests from your SAML app securely

Configure your XAA SAML App in Okta

Create the SAML 2.0 resource app in Okta

Create a SAML 2.0 requester app for testing

Register and configure the AI Agent in Okta

Verify your Okta XAA setup on xaa.dev

Configure SAML SSO

Confirm the SAML Assertion exchange for a refresh token

Verify the refresh token exchange for an ID-JAG token

Redeem the ID-JAG for an access token at the resource authorization server

Call the resource API with the access token

Prove the XAA connection end-to-end

Takeaways for implementors who have both OIDC and SAML apps

Learn more about Cross App Access, SAML, and OAuth 2.0

Mapping user identity in the SAML `NameID` attribute