This guide describes Ento's current organization-level single sign-on (SSO) behavior. Ento uses OpenID Connect (OIDC), with setup options for Google Workspace and Microsoft Entra ID.
SSO confirms who the user is. Ento continues to control which organizations and sites the user can access and what role they have.
Prerequisites and setup
The Ento organization must already exist before SSO can be configured. SSO does not create an organization or discover one from a user's email domain.
Setup requires:
- An Ento organization administrator to configure SSO under Settings > Single sign-on.
- Someone with sufficient access at the identity provider to register Ento as an OIDC application and provide the client ID and client secret.
- The Ento redirect URI shown on the configuration page to be registered exactly at the identity provider.
- For Microsoft Entra ID, the Microsoft tenant ID.
Ento currently offers configuration for one identity provider per organization: Google Workspace or Microsoft Entra ID. The Ento administrator can enable SSO after entering the required configuration.
Ento trusts the configured identity provider and uses its returned email claim to match the Ento user. It does not use the email domain to select or create an organization.
Example configuration screen from a local preview. The client details and URLs are illustrative.
Existing users
An existing accepted organization member connects SSO to their current Ento user. They can start this from Settings > Your Access or from their own row under Settings > Team Members.
The user signs in to Ento first, selects Connect, and then authenticates with the organization's identity provider. Ento connects the identity only when:
- The user already has access to the organization.
- The email returned by the identity provider is already recorded for that Ento user and exactly matches the user's Ento email, ignoring letter case.
- The identity is not already connected to another Ento user.
After connection, the organization SSO link can sign the user in. A user who starts SSO without an invitation or an existing connection is refused and told to sign in to Ento and connect SSO from Your Access.
An accepted member can connect the organization's SSO identity from Your Access.
New users and invitations
SSO does not require a separate invitation type. An organization administrator uses the normal Team Members invitation and chooses the user's Ento role and site scope as usual.
The normal Team Members invitation still assigns the Ento role and site scope.
When SSO is enabled for the organization, the normal invitation email automatically links to the organization's SSO flow. The invited user:
- Opens the invitation link.
- Selects Sign in with SSO.
- Authenticates with the identity provider using the invited email address.
- Is connected to the Ento user associated with the invitation.
- Has the pending membership and its assigned access activated.
The invitation and organization SSO URL lead to the organization's SSO sign-in page.
This first-time flow does not ask the user to create an Ento password. The signed SSO invitation link is valid for seven days. If it is invalid, expired, already accepted, or no longer matches an enabled provider, Ento asks the user to request a new invitation.
The current SSO invitation path also does not show the normal join form's terms-acceptance step. It is not clear from the current behavior where terms acceptance is recorded for these users.
If SSO is not enabled when the invitation email is generated, the invitation uses the normal Ento join link instead. That flow asks a new user to create a password. Resending the invitation after SSO has been enabled generates the SSO link.
Before setup or connection is complete
- If the organization does not exist, its organization SSO URL is unavailable.
- If SSO is missing or disabled, the organization SSO page says that SSO is not configured.
- SSO cannot be marked as required until the provider is enabled and a successful SSO sign-in has tested the configuration.
- While SSO remains optional, existing users can still use the normal Ento login and then connect SSO.
- An unconnected user cannot use the organization SSO URL as invitation-free account creation. They must use a valid invitation or sign in to an existing Ento user and connect SSO.
- Configuration or identity-provider errors are shown on an SSO error page. Incorrect client credentials and redirect URI errors have specific guidance.
Requiring SSO for browser access
After a successful test sign-in, an organization administrator can enable Require SSO for this organization. A non-staff administrator must have completed that test sign-in in the current browser session before enabling the requirement.
When SSO is required, an authenticated user who opens an Ento browser page for that organization is redirected to the organization's SSO page unless the current session has authenticated with that organization's current provider. A local password login by itself does not satisfy this check.
This requirement applies to organization-specific browser pages. It is not a global removal of Ento passwords and does not apply to API keys, OAuth access tokens, or every account-level page. Ento staff users bypass this browser enforcement for recovery and support purposes.
Changing important OIDC settings or disabling the provider clears the successful-test status and turns off required SSO. The updated configuration must be tested again before enforcement can be re-enabled.
Roles and site access
Roles and site access remain managed in Ento. OIDC claims do not assign or change Ento roles, organization membership, site access, or tag-based access.
For a new invitation, SSO activates the role and site scope that the Ento administrator assigned when inviting the user. For an existing member, connecting SSO leaves all current Ento access unchanged.
The SSO identity signs in to the user's existing Ento account, not to a separate account limited to one organization. After sign-in, the user retains access to every organization already granted to that Ento account. Each organization that requires SSO still requires authentication with its own configured provider.
A connected identity can sign in through the provider only while the Ento user is active and still has access to that organization. Deleting the organization's SSO configuration disconnects the SSO identities linked to that provider.
Questions and answers
Can I create the user with a normal invitation?
Yes. Use the normal Team Members invitation. If SSO is enabled when the email is generated, Ento automatically puts the SSO onboarding link in that invitation.
Does the user need a special SSO activation?
There is no special administrator-side invitation type. A new user connects SSO by completing the SSO invitation. An existing accepted member signs in to Ento and selects Connect under Your Access or on their own Team Members row.
Must the organization be created first?
Yes. SSO configuration belongs to an existing Ento organization and can be managed by an Ento organization administrator.
What happens if the user signs in before SSO is ready?
If SSO is optional, the user can use the normal Ento login. If they open an organization SSO URL before a provider is enabled, Ento says SSO is not configured. Required SSO cannot be enabled until the configuration has passed a successful SSO sign-in.
What happens if the user has not connected their identity?
Direct SSO sign-in is refused unless the user has a valid SSO invitation or the identity is already connected. An existing member can first use the normal Ento login and connect the identity. If SSO is required, opening an organization page after local login redirects the member to the organization's SSO flow, where the authenticated Ento user can be connected.
Do existing users keep their roles and site access?
Yes. Connecting SSO does not change Ento-managed roles or site access.
Does signing out of Ento also sign the user out of Google or Microsoft?
No. Ento sign-out ends the local Ento session only.
Not included at this stage
The current implementation does not provide:
- SCIM user provisioning or deprovisioning.
- SAML identity providers.
- Identity-provider group, role, organization, site, or tag mapping.
- Automatic Ento organization creation.
- More than one identity provider for the same Ento organization.
- Email-domain discovery of an organization's SSO page.
- Just-in-Time user creation without an Ento invitation.
- Ento-managed multi-factor authentication policies or a user control for disabling password login.
- Identity-provider logout, remote session revocation, or front-channel/back-channel logout.
Behavior across several SSO-enabled organizations is not fully verified. Ento stores the SSO context for one organization and provider in the current browser session, so a user may need to authenticate again when moving to another organization that also requires SSO.