Claude Enterprise-managed auth with Okta Cross App Access (XAA) - Beta Participation Guide
Last Updated:
This guide is intended only for Okta customers who are approved participants in the Anthropic Enterprise-Managed Auth beta.
Applies To
- Approved Claude Enterprise-managed auth (EMA) beta participants only
- Okta Identity Engine (OIE)
- Okta Cross App Access (XAA)
- Model Context Protocol (MCP) integrations with Claude
How Does EMA with XAA Address Enterprise AI Deployment Challenges?
Anthropic and Okta are partnering with a select group of MCP providers and customers to deliver EMA with XAA. This is an enterprise solution to streamline MCP access in Claude and remove user authentication and authorization friction. As a joint Anthropic and Okta customer participating in this beta, we invite you to test and share feedback on this feature.
This solution addresses two problems enterprises face when deploying AI agents at scale:
- End-user friction: Employees are interrupted by repeated sign-in and consent prompts every time an agent needs to reach another application. With EMA, employees sign in once through Okta as the IDP and Claude can then work across approved MCPs without additional authentication requests.
- Weak security control over MCP access: Users can connect personal Claude accounts with workplace MCPs. With EMA and XAA, authentication across participating MCPs is governed by the Okta IDP, preventing unauthorized data access outside enterprise accounts.
Okta Tenant Setup for EMA with XAA Beta Testing
The following sections describe the capabilities enabled in the Okta tenant as part of the EMA with XAA beta and the steps an Okta administrator must complete to prepare for beta testing.
Prerequisites for Okta Setup
Before beginning configuration, confirm the following conditions are met:
- Okta has enabled support for XAA in the Okta tenant (optionally in Okta Preview)
- Super Admin access is available in the Okta tenant
- A custom Security Assertion Markup Language (SAML) app federated with Claude exists in Okta
- Custom SAML app(s) federated with the MCPs under test exist in Okta, or the MCP apps have been installed from the Okta Integration Network (OIN)
- The users participating in the beta are assigned in Okta to both the Claude app instance and the MCP Resource Application app instances
NOTE: Do not make any changes outside the instructions provided in the prerequisites section above.
NOTE: The Resource Application called "MCP (Resource App)" shown in the following sections represents an existing MCP connection with one of the participating MCPs under test (for example, Figma, Asana, or Atlassian).
How to Configure Cross App Access in Okta MCP Applications
Updating the Okta Resource Application to Use XAA
NOTE: Complete this section for each MCP Resource Application under test.
Navigate to the target MCP application in the Okta Admin Console, enable XAA under the Resource Server tab, enter the Issuer URL provided by the MCP, and save the configuration.
- Sign in to the Okta Admin Console with a Super Administrator account.
- Navigate to Applications and select the existing MCP application under test (for example, Figma, Asana, or Granola).
- In the selected application, navigate to Resource Server and select Enable XAA.
- Enter the Issuer URL value provided separately by the MCP.
- Select Save.
NOTE: If the Issuer URL value is changed after completing the remaining instructions, the corresponding MCP Resource Connection assigned to the Okta AI Agent must be deleted, recreated, and reassigned. See the Resource Connections steps in the Configuring an Okta AI Agent section below for details.
Updating the SAML Application Username Format
Complete this section only when configuring a custom Okta SAML application instance — not an OIN application instance. These steps ensure the MCP federated application receives an email address as the SAML NameId format and that the NameId type is also set to Email.
- Navigate to Sign On and review the Application username format value.
- Proceed to steps 3 and 4 only if the Application username format is set to one of the following:
- Okta username
- Email Address
- A Custom value that injects the user's email (for example,
user.getInternalProperty("login")oruser.getInternalProperty("email"))
- Navigate to General > SAML Settings and confirm that Name ID Format is set to EmailAddress. If it is not set to EmailAddress, proceed to step 4.
- Select Edit, update the Name ID Format value to EmailAddress, then select Next and Finish to save the change.
How to Configure an Okta AI Agent
Registering and Configuring the AI Agent
Register a new AI Agent in Okta to represent the relationship between Claude as a Requester Application and one or more MCP Resource Applications, configure its credentials using a public key provided by Anthropic, add Claude as a delegated caller, and connect each MCP as a Resource Connection.
- Navigate to Directory > AI Agents.
- Select Register AI Agent > Register Manually.
- Register an agent to represent the relationship between Claude as a Requester Application and one or more MCP Resource Applications. The example name used in this guide is Claude (Requester App).
- Assign owners of the AI Agent on the next page and select Register.
NOTE: The owner assignment step is listed as optional in Okta but is required later if Skip for now is selected.
- Select the AI Agent just created — Claude (Requester App) — to open its configuration.
- Configure the agent across the following tabs:
- Profile — No input required.
- Owners — No input required.
- Credentials:
- Locate the AI Agent ID (this is a Client ID) and provide this value to Anthropic. Anthropic returns a public key.
- Select Add public key.
- Paste the public key provided by Anthropic and select **Done**.
- Delegations:
- Select Add Caller.
- Search for the Claude app and add it as a Requester.
- Select Add Caller to confirm.
- Resource Connections:
NOTE: Complete the following steps for each MCP Resource Application under test.
- Select **Add Resource Connection** and on the next page select **Application**.
NOTE: As noted in the Updating the Okta Resource Application to Use XAA section, if any Issuer URL values are changed in the Okta Resource Applications, the corresponding Resource Connection must be deleted, recreated, and reassigned to the agent.
- Configure the Application resource connection: - In Application instance, search for and select the MCP Resource Application to connect. - Enter the Client ID at resource. - Under Scope Condition, select Allow all.
- Repeat the Resource Connections steps for each additional MCP under test.
Confirm the AI Agent configuration is complete. All checkmarks on the agent configuration page must be green.
- In the AI Agent view, select Actions > Activate.
How the EMA with XAA Authentication Flow Works
The EMA with XAA flow executes across three roles: Claude as the Requester Application, Okta as the Identity Provider that manages app connections, and SaaS provider MCP servers as Resource Applications.
The end-to-end flow proceeds as follows:
- The user opens Claude and initiates sign-in. Claude redirects the browser to the federated Okta tenant. The user authenticates at Okta and is returned to Claude, signed in.
- XAA token exchange — Claude requests an Identity Assertion JWT Authorization Grant (ID-JAG) by sending the authenticated user's ID token from Okta and receives an ID-JAG token in exchange.
- When Claude needs access to an MCP resource, Claude provides the ID-JAG.
- The Resource MCP application validates the ID-JAG against Okta.
- Upon validation, the Resource MCP Authorization Server mints an access token and returns it to Claude.
- Claude uses the access token and provides it to the MCP Resource Server to retrieve the required information.
