How do I connect Arcade to Okta or Azure AD for SSO/SAML?

Quick Answer: You connect Arcade to Okta or Azure AD by setting up Arcade as a SAML 2.0 application in your IDP, downloading the SSO metadata, and adding it to your Arcade tenant. Once configured, users can sign in to Arcade via your identity provider with SSO/SAML and RBAC enforced at the Arcade layer.

Frequently Asked Questions

How does SSO/SAML with Okta or Azure AD work for Arcade?

Short Answer: Arcade acts as a SAML 2.0 service provider (SP), while Okta or Azure AD act as the identity provider (IDP). Users authenticate with your IDP, and Arcade enforces authorization and RBAC based on the SAML assertions.

Expanded Explanation:
Arcade is the MCP runtime between AI and action, so identity really matters. With SSO/SAML enabled, Arcade never becomes “yet another password system.” Instead, it defers authentication to your existing identity provider (Okta, Azure AD, etc.). When a user tries to access Arcade or an Arcade-powered agent console, they’re redirected to your IDP, complete sign-in (including MFA), and are sent back to Arcade with a signed SAML assertion.

Arcade uses that assertion to establish the user’s identity (typically via NameID or an email claim), map them into your tenant, and apply role-based access controls. The same identity is then used when agents act with user-specific permissions across tools like Gmail, Slack, GitHub, Salesforce, and more—so you get a consistent, governed identity story from login all the way down to tool execution.

Key Takeaways:

• Arcade uses SAML 2.0 to integrate with Okta, Azure AD, and other enterprise IDPs.
• Authentication happens in your IDP; Arcade focuses on authorization, RBAC, and safe tool execution.

---

What is the process to connect Arcade to Okta or Azure AD for SSO/SAML?

Short Answer: Create a SAML app in Okta or Azure AD, configure its SAML settings for Arcade, export the IDP metadata, then plug that metadata into your Arcade tenant and test sign-in.

Expanded Explanation:
The flow is the same pattern identity teams already know: define an enterprise application in your IDP, point it at Arcade as the SAML SP, exchange metadata, and then lock down which users/groups get access. From there, Arcade takes over: once a user is authenticated via SSO, Arcade enforces tenant isolation, RBAC, and secure tool access without you having to rebuild auth again for every integration.

This is a one-time setup per tenant. After that, every engineer, operator, or admin that touches Arcade (or manages agents and tools) goes through your standard Okta/Azure AD login, MFA, and conditional access policies.

Steps:

1. Create a SAML app in your IDP
   • In Okta: Admin → Applications → Create App Integration → SAML 2.0.
   • In Azure AD: Enterprise applications → New application → Create your own application → Integrate any other application you don’t find in the gallery → SAML.
2. Configure SAML basic settings for Arcade
   • Set Single sign-on URL / ACS URL to the Arcade SAML ACS endpoint for your tenant (e.g., https://app.arcade.dev/sso/saml/acs/<your-tenant-id>).
   • Set Entity ID / Audience URI to the Arcade SP identifier (e.g., https://app.arcade.dev/sso/saml/metadata/<your-tenant-id>).
   • Use Email address or userPrincipalName as the NameID.
3. Download the IDP metadata and configure Arcade
   • Export the SAML metadata XML from Okta/Azure AD.
   • In Arcade’s admin/settings, upload the metadata or paste the SSO URL, Entity ID, and certificate.
   • Assign users/groups in your IDP to the Arcade app and perform a test login.

---

What’s the difference between using Okta vs Azure AD for Arcade SSO/SAML?

Short Answer: Both Okta and Azure AD work with Arcade via standard SAML 2.0; the difference is mostly in admin UX and terminology, not in how Arcade enforces identity or authorization.

Expanded Explanation:
From Arcade’s point of view, Okta and Azure AD are just SAML 2.0 identity providers. The protocol, assertions, and security guarantees are the same. What changes is how you configure them and how you map users/groups:

• Okta tends to be more developer-centric and app-focused, with clear SAML app flows and per-app policies.
• Azure AD leans into Microsoft 365 integration and conditional access, with user and group management tightly coupled to your Microsoft tenant.

Arcade consumes the same SAML claims either way and applies your tenant’s RBAC model. Your agents still run with user-specific permissions, and Arcade continues to isolate tokens and tools from the LLM itself.

Comparison Snapshot:

• Option A: Okta:
  • Clean SAML app setup, app assignments, and per-app MFA policies.
  • Often preferred in orgs with diverse SaaS and strong app-level controls.
• Option B: Azure AD:
  • Deep Microsoft 365 alignment, conditional access, and device-based controls.
  • Often preferred in Microsoft-heavy environments.
• Best for:
  • Whichever IDP already owns your workforce identity. Arcade plugs into both; choose based on what your security team supports today.

---

How do I actually implement SSO/SAML for my Arcade tenant?

Short Answer: Coordinate with your identity/security team, configure the SAML app in Okta or Azure AD, wire the metadata into Arcade, then roll out SSO with a small test group before enforcing it tenant-wide.

Expanded Explanation:
The technical setup is fast; the real work is aligning with your security policies and rollout plan. In practice, you’ll want to:

• Decide which users and teams should get Arcade access.
• Align SAML attributes (like email, name, and groups) with the roles and permissions you plan to use in Arcade.
• Test SSO flows with a limited group, verify that agents and tools behave correctly, and then enforce SSO for all users.

Once SSO is live, you get one consistent login path for managing agents, tools, and deployments—whether you run Arcade in the cloud, your VPC, on-prem, or air-gapped.

What You Need:

• An Arcade tenant with admin access to configure SSO/SAML settings and RBAC.
• Admin access to Okta or Azure AD (or a security/IT partner) to create and manage the SAML application and assignments.

---

Why should I connect Arcade to Okta or Azure AD instead of using passwords?

Short Answer: Connecting Arcade to Okta or Azure AD gives you enterprise-grade SSO, MFA, and governance while letting Arcade focus on secure agent authorization, user-specific tool permissions, and auditability.

Expanded Explanation:
Production agents are multi-user systems, not single demo bots. If Arcade had its own password system, you’d end up duplicating MFA, lifecycle management, and access reviews—all the stuff your IDP already does well. That’s how shadow identity systems and security reviews go sideways.

By wiring Arcade into your existing IDP:

• Authentication is handled by Okta/Azure AD with your existing MFA, device policies, and conditional access.
• Arcade can concentrate on what it’s built for: secure agent authorization, scoped OAuth for tools (Gmail, Slack, GitHub, Salesforce, etc.), zero token exposure to LLMs, and detailed audit logs for every agent action.

You get a clean separation of concerns: IDP handles “who are you?”, Arcade handles “what can the agent do on your behalf across real systems?”

Why It Matters:

• Stronger security posture: Centralized identity (Okta/Azure AD), MFA, and access policies combined with Arcade’s permission gates, RBAC, and audit trails for every tool call.
• Less friction for teams: Users sign in with the same SSO flow they use everywhere else, while developers avoid re-implementing auth for every integration and agent.

---

Quick Recap

Connecting Arcade to Okta or Azure AD for SSO/SAML means treating Arcade like any other enterprise SaaS in your identity perimeter: you define a SAML app in your IDP, plug in Arcade’s ACS URL and Entity ID, share metadata, and roll out SSO to the right users and groups. From there, Okta/Azure AD own authentication, while Arcade owns secure agent authorization, user-specific tool permissions, and full auditability across Gmail, Slack, GitHub, Salesforce, and more—so your agents can move from chat to action without blowing up your security model.

Next Step

Get Started