Answers you can trust, from Codeables
Every page on Codeables is structured and verified — built so people and the AI agents they rely on can trust it. Explore more from the source behind this answer.
Explore CodeablesHow do I connect Arcade to Okta or Azure AD for SSO/SAML?
Quick Answer: You connect Arcade to Okta or Azure AD by configuring SAML/SSO in your IdP, adding Arcade as a SAML application, and exchanging SAML metadata so users can sign in to Arcade with your existing identity provider.
Frequently Asked Questions
How does SSO/SAML work with Arcade?
Short Answer: Arcade supports SSO/SAML so your users can authenticate via Okta or Azure AD instead of standalone passwords, while Arcade enforces authorization for agents and tools.
Expanded Explanation:
Arcade treats SSO/SAML as the front door to your MCP runtime: your IdP (Okta or Azure AD) is the source of identity, and Arcade uses that identity to drive user-specific permissions, RBAC, and auditability for your agents. The IdP handles login (MFA, conditional access, device checks), then posts a signed SAML assertion to Arcade. Arcade maps that assertion to a tenant and user, and from there, agents act with that user’s permissions—not a shared service account.
This separation is key: SSO/SAML gives you centralized auth policies; Arcade enforces which tools an agent can call, which OAuth scopes they can use (e.g., Gmail vs. Calendar), and how those calls are logged and governed. You get modern identity control at the perimeter, plus fine-grained authorization at the runtime between AI and action.
Key Takeaways:
- Arcade plugs into Okta or Azure AD as a standard SAML application.
- Your IdP owns login; Arcade owns agent authorization, tools, and audit trails.
What are the steps to connect Arcade to Okta or Azure AD?
Short Answer: Add Arcade as a SAML app in Okta or Azure AD, configure SAML settings and claims, upload SAML metadata on both sides, then test login with a pilot user.
Expanded Explanation:
The exact UI labels differ between Okta and Azure AD, but the flow is essentially the same: create a new SAML app, give it a name like “Arcade,” specify Arcade’s SAML ACS URL and Entity ID, configure NameID and any group/role claims, then download the IdP metadata (or certificate, SSO URL) and provide it to Arcade. Once both ends trust each other, you assign users or groups in the IdP, and they can sign in to Arcade with a single click.
You’ll typically roll this out in three phases: (1) configure and test in a sandbox or with a small admin group, (2) validate attribute mappings and group-based access, and (3) flip the switch for broader rollout once you’re confident sign-in and governance look right.
Steps:
- Create a SAML app in your IdP
- In Okta: Applications → Create App Integration → SAML 2.0.
- In Azure AD: Enterprise applications → New application → “Create your own application” → Set up single sign-on with SAML.
- Configure SAML details using Arcade values
- Set the ACS/Reply URL and Entity ID to the values provided in your Arcade admin/settings UI.
- Use email or UPN as the NameID; add group/role claims if you want RBAC from IdP groups.
- Exchange metadata and test
- Download the IdP metadata (XML) or note the SSO URL, Entity ID, and signing certificate, then paste/upload into Arcade.
- Assign a test user/group in your IdP, perform a login, and verify the user shows up correctly in Arcade with the expected access.
What’s the difference between using Okta vs. Azure AD for Arcade SSO?
Short Answer: Both Okta and Azure AD work with Arcade over SAML; the difference is primarily in admin UX and policy engines, not in how Arcade handles identity.
Expanded Explanation:
From Arcade’s perspective, Okta and Azure AD are just standards-compliant identity providers that issue signed SAML assertions. Arcade consumes those assertions the same way: it validates the signature, parses the NameID and attributes (like email, groups), and maps them to a tenant user with specific permissions and roles.
Where they differ is in how you manage them. Okta tends to be more opinionated for app-centric control and lifecycle management; Azure AD is often deeply integrated with Microsoft 365 and conditional access policies. Either one is fine—pick the IdP you already use as your system of record. The important part is that you leverage their policies (MFA, conditional access, device compliance) to harden login, and let Arcade handle the downstream authorization for agents and tools.
Comparison Snapshot:
- Option A: Okta
- Strong app catalog and provisioning, very developer-friendly SAML setup.
- Great fit if you’re already centralizing SaaS access in Okta.
- Option B: Azure AD
- Deeply tied into Microsoft 365, strong conditional access and device policies.
- Natural fit if your identity already lives in Microsoft Entra ID.
- Best for: Use whichever is your primary IdP today; Arcade’s SAML integration is built to work cleanly with both.
How do I roll out Arcade SSO/SAML safely across my org?
Short Answer: Start with a small admin group, validate SAML assertions and group-based role mappings, then expand to more users while monitoring logs and access patterns.
Expanded Explanation:
SSO/SAML is powerful, but it’s also where mistakes hurt: a bad attribute mapping or mis-scoped group assignment can over-provision access. The practical way to roll out Arcade SSO is to mirror how you’ve rolled out other critical apps (GitHub, Salesforce, etc.):
- Create an Arcade app in Okta/Azure AD with limited assignment (admins only).
- Validate that email/UPN and groups map correctly into Arcade roles.
- Confirm that SSO works in different scenarios (direct link, IdP-initiated login, new users).
- Then use group-based assignment in your IdP to expand usage by team (e.g., “AI Builders,” “Support,” “Sales”).
Throughout, leverage your IdP’s controls—MFA, conditional access, sign-in risk—and combine them with Arcade’s authorization model: RBAC, scoped tools, and audit logs for every agent action.
What You Need:
- An existing Okta or Azure AD tenant with SAML SSO enabled and admin access.
- Access to Arcade’s admin/settings area to configure SSO/SAML, review logs, and manage roles.
Why should I connect Arcade to Okta or Azure AD instead of using standalone logins?
Short Answer: Connecting Arcade to Okta or Azure AD lets you apply your existing security policies to agents, tie every tool call back to a real user, and simplify lifecycle management as your deployment scales.
Expanded Explanation:
Production agents are multi-user systems. If you treat Arcade as “just another SaaS login,” you end up manually managing accounts, forgetting to deprovision users, and trying to bolt on governance after the fact. With SSO/SAML via Okta or Azure AD, you plug Arcade into the identity system you already trust:
- Every Arcade login flows through your IdP’s rules: MFA, location and device checks, conditional access.
- When a user leaves the company or changes teams, you update them once in the IdP. Their Arcade access adjusts automatically via group/role mappings.
- Audit logs in Arcade can be correlated with IdP logs so you can answer questions like “Who authorized this Gmail scope?” or “Which user’s identity was used when this agent updated Salesforce?”
For AI agents that can send emails, create calendar events, or modify customer records, this alignment matters. You don’t want a mystery “bot user” touching production systems; you want user-specific permissions, enforced by Arcade, anchored in a real identity from Okta or Azure AD.
Why It Matters:
- Stronger security posture: MFA, conditional access, SSO, and zero token exposure to LLMs working together.
- Cleaner operations: centralized onboarding/offboarding, consistent access control, and clearer audit trails for every agent action.
Quick Recap
Connecting Arcade to Okta or Azure AD for SSO/SAML is about giving your agents a trustworthy identity layer. You configure Arcade as a SAML app in your IdP, exchange metadata, and map attributes like email and groups into Arcade roles. From there, your IdP handles login and policies; Arcade handles agent authorization, tool execution, and auditability so agents can safely act across Gmail, Slack, GitHub, Salesforce, and more with user-specific permissions—not service accounts.