Skip to main content
Unlayer Docs

Enterprise SSO

Enterprise SSO lets your team sign in to the Unlayer Console through your company identity provider, such as Okta, Microsoft Entra ID, or another SAML or OIDC provider. Contact Unlayer to arrange Enterprise SSO for your workspace.

SSO authenticates your Console team. Your application remains responsible for end users inside your embedded editor; see End-User Identification and Security Settings.

Set up your workspace​

Your Unlayer contact helps configure the connection and verify your company's email domains. Start with SSO optional so existing password and Google sign-in remain available. A workspace owner or admin must successfully test SSO with the saved configuration before SSO can be required.

Each verified domain routes to one connection. Connections authenticate users; they do not isolate data within a workspace. Use separate workspaces when separate customer populations must not share data or access.

Sign in​

  1. Open the Unlayer sign-in page and choose Sign in with Enterprise SSO.
  2. Enter your work email address.
  3. Complete authentication with your company's identity provider.

Successful SSO can verify the matching email on an existing passwordless Unlayer account. An unverified account with an existing password or Google sign-in cannot be automatically linked, even when invited or when SSO is required. Contact Unlayer support for secure account recovery; simply verifying the email does not establish who created the earlier credentials. Previously verified accounts keep their existing sign-in methods, subject to the workspace SSO policy.

Your verified email domain selects the company connection. If an existing Unlayer account with that email is outside the workspace, an administrator must invite the account before it can be linked. Contact your administrator if Unlayer reports conflicting accounts or a suspended membership.

Choose optional or required SSO​

With optional SSO, members can continue using their existing sign-in methods. With required SSO, governed members must authenticate through their company's connection to access the workspace. A personal email address outside the configured domains is not automatically governed unless its account is linked to that SSO organization.

Enabling required SSO signs governed users out of Unlayer, including sessions used for other workspaces, and revokes their OAuth refresh tokens for this workspace. Existing sessions and delegated credentials must satisfy the workspace's current SSO policy when accessing protected resources.

Passwords are retained so an administrator can roll the policy back to optional. Changing authentication settings requires saving them with SSO optional and completing another owner/admin SSO test before requiring it again. A verified domain cannot be removed or made unverified while a linked member or an authenticated pending invitee still uses it for their Unlayer login or identity-provider profile. Update those accounts, cancel their pending invitations, or remove their workspace access first. Disabling the connection remains available for recovery.

Add and remove members​

Workspace admins manage membership from Team. Invite members before their first SSO login. An invited person can authenticate through SSO even when JIT is disabled, then must accept the invitation before receiving workspace and project access. The invitation's project selection and role are preserved; a pending invitation does not grant access automatically, even with JIT enabled.

After signing in, invitees can open /invites in Console to view and accept pending invitations, or follow the link in their invitation email.

Alternatively, arrange optional automatic membership creation on first login (just-in-time provisioning, or JIT). JIT-created users receive an Embed workspace membership with the member role. Without project-specific assignments, that membership can access all Embed projects in the workspace. Use invitations with selected projects when access must be restricted from the start; admins can also manage roles and project assignments afterward.

Workspaces without an active SSO connection retain their existing Console access: workspace membership allows opening sibling Embed projects, even when the person has other project assignments. Enabling SSO makes those assignments restrictive for ordinary members. Disabling SSO restores the existing Console behavior. API, MCP, and Email Sending keep their separate project-access checks.

When someone leaves your company, disable their identity-provider account and remove their workspace access in Unlayer. Disabling the identity-provider account alone does not revoke an existing Unlayer session. This release does not include automatic directory provisioning or offboarding through SCIM.

Removing an SSO workspace member signs that user out of Unlayer and revokes their credentials scoped to that workspace, removes workspace/project memberships, and records an explicit access block. While SSO is active, an owner or admin must use Restore SSO access before the member can sign in again. Restoring SSO access allows the person to join again; it does not recreate deleted roles, project assignments, or tokens. JIT never clears an access block. If SSO is disabled, accepting a fresh invitation restores membership and clears the old block for that SSO connection, so re-enabling SSO preserves the restored access. Workspace owners cannot be removed; transfer ownership first.

For members restricted to specific projects, removing their final project assignment also removes their workspace access and requires a workspace owner or admin. Concurrent removals do not turn restricted access into access to every project. This applies to both SSO and non-SSO workspaces; non-SSO removal preserves sessions for other workspaces.

API access​

Personal access tokens cannot prove an SSO login. For a user governed by required SSO, that workspace is hidden from PAT discovery and cannot be accessed with a PAT. The token itself is retained when required SSO is activated, so changing back to optional can restore its use. Explicitly removing a member revokes their scoped credentials.

OAuth and MCP connections for a protected workspace must be authorized after signing in through its SSO connection. Project API keys are machine credentials and are unaffected by the interactive SSO policy. See Server authentication.

Troubleshooting​

  • Connection not found: check the work email and verified domain with your administrator.
  • Workspace access unavailable: sign in through the workspace's SSO connection.
  • SSO access suspended: ask an owner or admin to review and explicitly restore your access.
  • Identity provider unavailable: contact your IT administrator. Your Unlayer contact can explicitly change the workspace policy back to optional if needed.

Existing members and connection replacement​

Existing workspace members can authenticate through required SSO even if they do not have Embed access. Signing in does not grant that access when JIT is off. A pending invitation also waits for explicit acceptance, including when JIT is on; acceptance adds its products and project role while preserving existing access.

To replace a WorkOS organization, contact your Unlayer administrator. Disable the old connection, then use Replace connection in Admin with the new WorkOS organization ID. Configure the same domains in the new WorkOS organization first. The replacement transfers all domains and suspension records atomically. Old identities and suspension history remain on the disabled connection; old profiles are not reassigned to the new organization. Removed users remain suspended. Activate the replacement with regular sign-in allowed, test an owner or admin login, then require SSO. Replacement does not restore removed access automatically.

Existing workspace administrators​

Enabling SSO does not remove a workspace administrator's existing access to projects in Console. Project-specific invitations still grant access only to the assigned projects for ordinary workspace members. Administrators must complete SSO when their workspace requires it, just like other governed members. Existing API and MCP project restrictions continue to apply.

Session revocation timing​

Session validation is cached for up to 60 seconds. After enabling required SSO or removing an SSO member, existing sessions may take up to 60 seconds to recognize the sign-out. Workspace access checks still enforce the current SSO policy and membership. Issuing new OAuth authorization grants checks the session directly without using this cache.