Enterprise SSO: Okta, SAML 2.0, OIDC and JIT provisioning

Eddie AI supports enterprise single sign-on (SSO) using SAML 2.0 or OpenID Connect (OIDC) through WorkOS AuthKit. This includes Okta, Microsoft Entra ID (formerly Azure AD) and Google Workspace, using a compatible connection configured with the Eddie team.

Eddie also supports just-in-time (JIT) provisioning into a configured team workspace. SCIM 2.0 directory provisioning is not currently integrated into Eddie Cloud. SSO and JIT do not provide automatic directory synchronization or offboarding.

Supported identity capabilities

Capability	Eddie Cloud support	What this means
SAML 2.0 SSO	Supported through WorkOS	Authenticate through your configured corporate identity provider.
OIDC SSO	Supported through WorkOS	Authenticate through an enterprise OpenID Connect connection. The provider must support that connection type.
Okta	Supported	Configure an Okta SAML 2.0 or OIDC connection with the Eddie team.
Microsoft Entra ID	Supported	Configure a compatible enterprise SSO connection with the Eddie team.
Google Workspace	Supported	Configure enterprise SSO with the Eddie team. Ordinary “Sign in with Google” is a separate login option.
JIT provisioning	Supported for configured team workspaces	Create or activate a workspace membership when an authenticated user first accesses Eddie.
Manual invitations	Supported	Invite teammates by email before they have an Eddie account. Their pending membership activates when they sign in with that address.
SCIM 2.0 / Directory Sync	Not currently integrated	Directory-driven user creation, updates, suspension and removal do not automatically synchronize into Eddie Cloud.
Directory group-to-role mapping	Not currently integrated	IdP groups do not automatically assign Eddie owner, admin or member roles.

For a private-cloud or on-prem deployment, ask the Eddie team to confirm the identity capabilities included in your specific deployment and agreement.

How SSO works

Start sign-in in Eddie with your work email and choose the enterprise SSO flow when offered. Eddie looks up the active WorkOS connection for your email domain and sends you to your organization's identity provider. After successful authentication, you return to Eddie.

WorkOS handles the SAML or OIDC federation. Eddie receives the authenticated user and, when available, the WorkOS organization associated with that session. You do not need a separate Eddie password for this flow.

Your identity provider applies its policies, including MFA and conditional access, during authentication. Those policies must be configured in your IdP. Enabling SSO does not by itself configure MFA, set Eddie session timeouts, or prove that every alternative sign-in method has been disabled. Agree on the required sign-in policy and test it with the Eddie team during setup.

JIT provisioning: what happens on first access

JIT means Eddie creates or activates the person's team membership as part of authenticated access, rather than waiting for a directory synchronization job. It requires your WorkOS organization and company domains to be bound to the correct team workspace by the Eddie team.

• New members join the team's workspace with the member role and use its shared credit pool. JIT does not give each person a separate team credit allowance.
• Existing roles are preserved. Signing in does not demote an existing owner or admin or promote a new member to an administrator.
• A removed membership stays removed. JIT does not automatically reactivate a deactivated team seat.
• Workspace matching is explicit. Eddie uses the configured WorkOS organization or an explicitly bound company email domain. It does not guess from a company name or match arbitrary similar domains.
• SSO connection setup and workspace setup are separate. A working SSO connection alone does not guarantee that users join your team workspace. If a binding is missing, conflicting or unavailable, Eddie can fall back to a personal workspace. A deactivated team seat can also fall back to personal access; removal from a team is not global account deletion.

JIT is not a directory allowlist: an explicitly bound company email domain can resolve a team workspace even when the authenticated session has no organization claim. If your policy requires only directory-assigned users to join, discuss that requirement with the Eddie team before rollout. Do not assume JIT checks synchronized group membership.

SCIM, directory synchronization and group provisioning

WorkOS offers Directory Sync, including SCIM integrations. Eddie Cloud does not currently consume those directory events to manage workspace memberships. WorkOS supporting SCIM does not make it enabled in Eddie by default.

Today, Eddie Cloud does not provide an Eddie SCIM endpoint or customer-ready SCIM setup instructions. Do not configure Okta provisioning against an assumed Eddie URL. The following are not automatic today:

• Provisioning team members before their first sign-in from a directory assignment.
• Synchronizing name or email changes and group membership into Eddie roles.
• Suspending or removing an Eddie team seat when a directory user is disabled, deleted or unassigned.
• Revoking all Eddie sessions and tokens as a consequence of a SCIM deprovisioning event.

Use JIT and manual workspace invitations for onboarding. If you require SCIM, share your provisioning and offboarding requirements with sales. Ask for confirmation of delivered capabilities before treating directory provisioning as available.

Offboarding and existing sessions

For offboarding today, remove the person's Eddie workspace membership using Manage members and disable or unassign access in your identity provider. These are separate actions. Changing IdP assignment prevents new authentication according to the IdP's policy; it does not automatically remove the stored Eddie membership.

Eddie's web session handling periodically checks WorkOS session status, at most once every five minutes when that session path runs. A definitive revoked or missing WorkOS session ends the web session. A WorkOS outage or an inconclusive response leaves it active, and older sessions without a WorkOS session identifier cannot use this check.

This is not a guarantee of revocation within five minutes across all clients. Existing desktop/mobile bearer tokens, connected AI clients and other authenticated access paths have separate validation behavior. For an incident requiring immediate termination of all access, contact support to confirm the required scope and actions. Removing a seat does not delete the company's projects or revoke separately shared public review links.

Set up Okta, SAML 2.0 or OIDC

SSO setup is coordinated with the Eddie team. There is no end-user SSO configuration toggle in Eddie.

1. Contact sales. Share your IdP, desired protocol, company domains, target Eddie workspace and IT administrator contact. Include whether you require JIT, SCIM, group mapping or strict SSO-only access.
2. The Eddie team configures a WorkOS organization and connection. Your IT administrator configures the corresponding application in Okta, Entra ID, Google Workspace or another compatible provider.
3. For SAML 2.0, use the exact service-provider entity ID and ACS URL provided for that connection. Supply the IdP metadata and signing certificate as requested. For OIDC, use the connection's supplied redirect URI and required issuer/discovery and client configuration. Exchange client secrets through the setup process, not a public help page.
4. Agree on the email attribute, verified company domains, application assignments and IdP authentication policies. The Eddie team binds the organization and allowed domains to your team workspace.
5. Test with an assigned user. Confirm successful sign-in, the correct team workspace, the member role, preserved existing roles and shared credits. Test a removed seat, an unassigned user and any alternate sign-in methods required by your policy. Confirm existing-session behavior during offboarding.

Connection URLs and identifiers are specific to your setup; this article intentionally does not provide reusable ACS URLs, issuer values or SCIM credentials. Existing personal projects and credits are not automatically migrated into the team by signing in. Discuss any migration with the Eddie team.

Answers for security questionnaires

• Does Eddie support Okta? Yes, enterprise SSO through WorkOS with a configured Okta SAML 2.0 or OIDC connection.
• Does Eddie support SAML 2.0 and OIDC? Yes, for enterprise SSO through WorkOS. Confirm the protocol selected for your connection during onboarding.
• Does Eddie support JIT? Yes, workspace membership is provisioned on authenticated access for a configured organization/domain binding, with new seats assigned the member role.
• Does Eddie Cloud support SCIM provisioning and deprovisioning today? No. WorkOS Directory Sync has not been integrated into Eddie Cloud membership lifecycle management.
• Does disabling an IdP user immediately revoke all Eddie access? Do not assume this. Remove the Eddie workspace seat and confirm existing-session/token revocation requirements with the Eddie team.

Related: Invite your team to a workspace, Manage members, Workspace credits and visibility, Legal, security and compliance, Contact support.