Enterprise SSO

Company Workspaces can connect a company identity provider over SAML 2.0. Okta is the reference setup; Azure AD / Entra, Google Workspace, OneLogin and other SAML IdPs work the same way. SSO is configured per customer after the company Workspace is provisioned. Contact notifications@codenskills.com to start the setup.

How sign-in works

Provisioning is just-in-time (JIT): accounts and memberships are created and updated automatically at sign-in, with no manual invitations.

1. On the login page, choose Use SSO and enter your work email.
2. Your email domain is matched to your company's identity provider and you authenticate there.
3. On every sign-in, your account is joined to your company's workspace with a role derived from your IdP groups (group mappings, configured per company), and those groups are synced into the workspace as externally managed groups.

Admins can grant skill access to IdP groups directly — membership then follows your identity provider, with changes applied at each sign-in.

Requiring SSO

Owners and admins can require SSO for the connected domain from Settings → Security → Require single sign-on. Once enabled, members on that domain can no longer sign in with a password or Google and must use the identity provider. Owners and admins keep password/Google access as a recovery path, so a misconfigured provider cannot lock the workspace's managers out.

What your IT team sets up

We send a short guide; the summary:

1. Create a SAML 2.0 app in the identity provider with the ACS URL and Entity ID we provide.
2. Map the standard attributes (email, firstName, lastName) and add a groups attribute statement with a filter agreed with us — every group that passes the filter becomes a visible group in the workspace, so a scoped filter is recommended.
3. Assign the app to the users and groups that should have access.
4. Send us the app's metadata URL and the email domain your users sign in with.

No secrets are exchanged: trust is established through the SAML metadata.

Good to know

• Provisioning is JIT only: group and role changes apply at the next sign-in, and removing a user in the IdP blocks new sign-ins but does not end active sessions (SCIM directory sync is on the roadmap).
• An SSO account is separate from a password or Google account that uses the same email address. This is why owners and admins keep a non-SSO recovery path even when SSO is required.
• Workspace roles derived from groups only move between admin and member — workspace ownership is never changed by SSO.
• One email domain maps to one company workspace.
• During billing offboarding, owners first disable SSO enforcement. Support then removes the SSO connection and IdP-managed groups before the workspace can be downgraded. Existing approved skills remain available while governance is paused.