Cross App Access

Cross App Access (XAA) lets an AI agent your users have approved in Okta call Kindo’s MCP gateway (/v1/mcp) on their behalf, without ever handling a Kindo API key. Okta issues a short-lived, user-bound token (an ID-JAG) that the approved app redeems directly with Kindo for a Kindo access token scoped to kindo.mcp. Kindo never sees the user’s Okta credentials, and the app never handles a Kindo API key or the user’s credentials. Each Kindo access token it redeems is short-lived — one hour, with no refresh token.

Prerequisites

The organization has a configured SAML SSO connection to Okta. Cross App Access resolves the calling user by matching the ID-JAG’s SAML subject against that connection’s accounts.
Each user has signed in to Kindo through that SAML connection at least once. Cross App Access only matches users who already have a Kindo account linked to the connection.
The Okta SAML app sends a persistent, email, or unspecified NameID format. Transient NameIDs aren’t accepted. The ID-JAG’s subject issuer must also be the SAML connection’s IdP entity ID.
An Okta administrator can create an OIN (Okta Integration Network) resource-app entry, or configure Cross App Access for an existing app, in the Okta admin console.
Kindo Support or your account team has enabled Cross App Access for your organization.

Values to give Okta

Configuring the Kindo side of an Okta resource-app entry needs five values:

Value	Where it comes from
Issuer URL	`<API_BASE_URL>/oauth` — shown on the Cross App Access settings screen.
Resource	`<API_BASE_URL>/v1/mcp` — shown on the Cross App Access settings screen.
Audience/tenant ID	Your Kindo organization ID — shown as Audience tenant ID on the Cross App Access settings screen. Required: Kindo refuses any ID-JAG that doesn’t carry it.
Scope	`kindo.mcp`
Client ID and secret (or a CIMD URL)	Created from the Cross App Access settings screen — see Approve a client below.

API_BASE_URL is your Kindo deployment’s API origin (for example https://api.kindo.ai, or your self-hosted deployment’s equivalent).

In Okta, paste the Issuer URL and Resource, and enter the audience tenant ID in the Audience/tenant ID field on the app’s resource connection (the Resource Server tab, next to the Issuer URL). Kindo uses that ID to find your organization, so more than one Kindo organization can trust the same Okta org.

Configure Cross App Access

An org admin opens Settings → SSO. The Cross App Access section sits next to the SSO connection settings and is visible once your organization has Cross App Access enabled.
Enter the Okta org URL your users sign in through (for example https://acme.okta.com) as the Okta org URL. This is the trusted issuer — Kindo only accepts ID-JAGs issued by this Okta org. Once saved, the value is normalized to the issuer Okta’s own OIDC discovery document reports.
Select the SAML connection this configuration resolves users against — normally the same connection your organization uses for SSO sign-in.
Copy the Issuer URL, Resource, and Audience tenant ID shown on this screen into the Okta resource connection (see Values to give Okta). The Audience/tenant ID is required.
Toggle Enabled and select Save.

Approve a client

Cross App Access only accepts a redemption from a client an admin has explicitly approved. There are two kinds:

Pre-registered client — choose the client’s authentication method from the dropdown next to Create client, then select Create client:
- Secret in request body (client_secret_post) — the default. Use this for VS Code’s MCP OAuth client and most other clients.
- Secret in Authorization header (client_secret_basic).
The client is created immediately with an automatic name (for example, “Kindo XAA client 9/25/2026”) — there’s no separate naming step. Kindo shows the client ID and secret exactly once. Copy the secret before closing the dialog — Kindo never displays it again.
CIMD (Client ID Metadata Document) client — paste the client’s own metadata-document URL (for example https://client.example.com/.well-known/client-id-metadata.json) under Approve CIMD client. Kindo fetches and validates the document the first time that client redeems an ID-JAG; until then it’s listed by its URL alone, with no creation date.

The approved-clients list shows each client’s name, type, and — for a pre-registered client — its authentication method.

Statuses

The Cross App Access section shows one of these statuses:

Status	Meaning
(section hidden)	Cross App Access isn’t enabled for your organization.
(prompt to set up SSO)	Your organization has no configured SAML connection yet.
Not configured	SAML is configured, but no Cross App Access trust configuration has been saved yet.
Needs attention	A configuration exists, but at least one problem below needs fixing before it will admit a token.
Ready	Configured, enabled, and at least one client is approved — Okta-issued ID-JAGs can be redeemed.

A Needs attention status lists the specific reason:

The bound SAML connection is missing or no longer configured. — Reconnect or recreate the SAML connection under Single Sign-On (SSO) Setup.
No clients are approved yet. — Approve at least one client (see Approve a client).
Cross App Access is turned off. — Toggle Enabled and save.

Revoking and removing

Revoke a client — select Revoke on a client’s row. A pre-registered client’s Kindo registration is deleted outright, so its next redemption attempt fails. A CIMD client loses its approval and is denied on its next redemption; if it had already self-registered a record on an earlier redemption, that record stays and is simply no longer approved. Either way, Kindo rechecks on every call, so the client’s already-issued Kindo access tokens are also rejected on their next /v1/mcp call, even though they otherwise last up to an hour.
Remove Cross App Access — select Remove Cross App Access to delete the entire configuration and every pre-registered client’s Kindo registration. A CIMD client loses its approval instead — if it had already self-registered a record on an earlier redemption, that record stays but is no longer approved. Kindo access tokens already issued to those clients are also rejected on their next /v1/mcp call. This also frees the bound SAML connection to be deleted, if you no longer need it. This cannot be undone. If Cross App Access is later turned off for your organization while a configuration still exists, this remove option stays available so you can still remove the configuration (and then delete the SAML connection).

Troubleshooting

xaa.dev’s resource-app tester health check fails. Point its health-check path at /healthcheck on your API origin — the API’s existing probe endpoint. xaa.dev lets you change the health-check path from its default.
A pre-registered client fails with “client is not linked to resource(s)”. A pre-registered client’s link to the Kindo MCP resource is recorded at client-creation time, using the API URL configured then. If your installation’s API URL changes, every existing pre-registered client stops redeeming, and the Issuer URL and Resource values given to Okta (see Values to give Okta) need updating to match. Create a new pre-registered client (see Approve a client) rather than reusing the old one.
An ID-JAG redemption fails with “Assertion has expired.” An ID-JAG expires about five minutes after Okta issues it. Request a fresh one from Okta.
An ID-JAG redemption fails with “This assertion has already been redeemed.” An ID-JAG is single-use. Request a fresh one from Okta rather than retrying the same one.
An ID-JAG redemption fails with “No Kindo account matches this SAML subject.” The user has no Kindo account linked through the bound SAML connection. Have them sign in to Kindo with SAML SSO once, then request a fresh ID-JAG.
An ID-JAG redemption fails with “Assertion has no aud_tenant.” The Okta resource connection has no Audience/tenant ID. Enter your Kindo audience tenant ID (see Values to give Okta) in that field, then request a fresh ID-JAG.
An ID-JAG redemption fails with “Issuer is not trusted for this client.” Check that the Okta resource connection’s Audience/tenant ID exactly matches the Audience tenant ID shown in Kindo’s Cross App Access settings, that the Okta org URL in Kindo matches your Okta org, and that the client is approved (see Approve a client). Then request a fresh ID-JAG.
An ID-JAG redemption fails with “Transient NameID subjects are not accepted.” The Okta SAML app is sending a transient NameID. In the app’s SAML settings, set the NameID format to persistent, email address, or unspecified, then request a fresh ID-JAG.
xaa.dev’s playground mode is refused with “Assertion has no aud_tenant.” The playground doesn’t send an aud_tenant, so test through your own Okta org instead.
xaa.dev can’t reach the Kindo API, or the MCP call step is blocked by CORS. xaa.dev redeems ID-JAGs server-side, so the Kindo API must be publicly reachable over HTTPS for that tester to use it. For the MCP call step specifically, use xaa.dev’s Proxy Mode if a direct browser call is blocked by CORS.

Cross App Access and Personal API Key Access

Cross App Access is not gated by the Personal API Key Access user-group entitlement (see User Groups) — that setting only affects a user’s own Kindo API key. A user whose personal API key access is disabled can still be admitted through Cross App Access, provided their org’s configuration is ready and an Okta admin has approved them for the resource app.