Enterprise SSO for AI Platforms: SAML, OIDC & SCIM Guide
Set up enterprise SSO for your AI agent platform. Step-by-step guides for Okta, Azure AD, Google Workspace, plus SCIM 2.0 auto-provisioning.
What you will learn
- Choose between SAML 2.0 and OIDC for your organization
- Configure SSO with Okta, Azure AD, or Google Workspace
- Set up SCIM 2.0 for automated user provisioning and deprovisioning
- Enforce SSO-only login across your AI agent platform
- Pass the SSO portion of a SOC 2 audit on the first pass
TL;DR — If your AI agent platform touches production systems or customer data, SSO is not optional. Pair SAML or OIDC (for login) with SCIM (for lifecycle) and you get one-click offboarding, fewer forgotten accounts, and a cleaner SOC 2 audit.
Why SSO for AI Platforms?
When AI agents have access to production systems, code repositories, and customer data, access control is not optional. SSO ensures that only authenticated employees can configure agents, approve actions, or view audit trails — using the same identity provider that manages the rest of your IT infrastructure.
Each team member creates a separate account with email/password. When someone leaves the company, their Dobby account stays active until someone remembers to delete it manually. Ex-employees retain agent access.
All users authenticate through your corporate SSO. When someone is offboarded in Okta, their Dobby access is automatically revoked via SCIM. Zero manual cleanup.
Supported Identity Providers
- Okta — SAML 2.0 + OIDC + SCIM 2.0
- Azure Active Directory — SAML 2.0 + OIDC + SCIM 2.0
- Google Workspace — OIDC (built-in OAuth)
- OneLogin — SAML 2.0 + OIDC
- Ping Identity — SAML 2.0 + OIDC
- Custom SAML — any SAML 2.0 compliant IdP
- Custom OIDC — any OpenID Connect compliant IdP
SAML vs OIDC — Which to Choose?
SAML 2.0 is the enterprise standard — mature, widely supported, XML-based. OIDC is the modern alternative — lightweight, JSON-based, built on OAuth 2.0. Both work well. Choose based on what your IdP recommends.
- SAML 2.0 — Best for: Okta, Azure AD, legacy enterprise IdPs. XML assertions, X.509 certificates.
- OIDC — Best for: Google Workspace, modern IdPs, mobile apps. JWT tokens, simpler integration.
- Both — All 7 supported providers work with at least one protocol. Some support both.
Setup Steps (Okta Example)
In Okta Admin Console, create a new SAML 2.0 application. Set the ACS URL to https://dobby-ai.com/api/auth/callback/saml and the Entity ID to dobby-ai-{org_id}.
Download the IdP metadata XML or copy the SSO URL, Entity ID, and X.509 certificate from Okta.
In Dobby, go to Organization Settings → SSO. Paste the IdP metadata and save. The platform validates the certificate and tests the connection.
Enable 'SSO Required' to enforce SSO-only login. Users can no longer sign in with email/password — only through the corporate IdP.
All SSO secrets (OIDC client secrets, SAML certificates) are encrypted with AES-256-GCM before storage. They never appear in logs or API responses. Key rotation is supported without downtime.
SCIM 2.0 Provisioning
SCIM (System for Cross-domain Identity Management) automates user lifecycle management. When you add a user in Okta, they are automatically created in Dobby with the correct role. When you deactivate a user in Okta, their Dobby access is revoked immediately.
- Create — new employee added in IdP → user created in Dobby with assigned role
- Update — role change in IdP → role updated in Dobby automatically
- Deactivate — employee offboarded in IdP → Dobby access revoked within minutes
- Group sync — IdP groups map to Dobby roles (admin group → admin role)
SCIM is critical for SOC 2 compliance. Auditors check that access is revoked promptly when employees leave. SCIM makes this automatic — no manual cleanup, no forgotten accounts, no access gaps.
Common Pitfalls (and How to Avoid Them)
- Not enforcing SSO — users keep password logins alive and bypass the IdP. Always set 'SSO Required' after validation.
- Missing group mapping — SCIM provisions the user but not the role. Map at least one IdP group to an admin role.
- Certificate expiry — SAML certs expire silently. Set a calendar reminder 60 days before the X.509 expiry.
- Break-glass account — if SSO breaks, you are locked out. Keep exactly one emergency local admin account, rotated and stored in a vault.
Frequently Asked Questions
Does SSO work with our MCP / API integrations?
Yes. Human users authenticate via SSO; automation uses separate service keys (sk_live_*, gk_svc_*) that are scoped, revocable, and logged independently. This separation lets you offboard humans without breaking production agents.
How long does SSO deprovisioning take?
SCIM pushes deactivation within seconds of the IdP event. Active sessions are terminated on next request (within about one minute). For immediate cutoff during an incident, combine with a manual session revoke from the dashboard.
Can one user belong to multiple organizations?
Yes. Each organization configures its own SSO connection, and a user sees the orgs they have been provisioned to. Role and access scope are per-organization.
What happens if our IdP goes down?
Existing sessions remain valid up to their expiry. New logins are blocked until the IdP recovers. Use the break-glass admin account for genuine emergencies — it is the only local account that remains when 'SSO Required' is enforced.