This article explains the different ways users can sign in to Yoodli, how to configure SAML-based SSO for your organization, and how to control which sign-in options appear on your org’s login page.
1. Standard sign-in options
By default, Yoodli provides the following sign-in methods to all users and organizations:
Email + password
Google
Microsoft
These options can be enabled or disabled at the organization level (see Enforce specific sign-in options below).
2. Single Sign-On (SSO) overview
Each enterprise organization can configure one additional SSO method with another identity provider (IdP), such as Okta or Entra ID. If SSO is configured, the sign-in page will not show other methods.
Yoodli supports:
SAML 2.0 (self-serve configuration in the admin view)
OpenID Connect (OIDC) (configured with Yoodli support)
Note: Yoodli supports Service Provider (SP)–initiated sign-in only. IdP-initiated sign-in is not supported.
When an SSO option is configured, no other login options will be shown unless the “Allow admin email sign-in” setting is enabled. Enabling that setting will expose an “Admin sign-in” option on the login page which will show all the standard login options.
3. Requirements for SAML SSO
To configure SAML SSO, your IdP must be able to supply:
An IdP Entity ID
An SSO URL (login URL)
A certificate in base64 format
And the SAML assertion must provide:
A valid email address in the NameID field
If NameID is not a valid email, or the email is only sent in other attributes, Yoodli will reject access.
This cannot be overridden to use a different attribute.
Yoodli uses SAML attributes to determine the user’s display name in this order:
urn:oid:2.16.840.1.113730.3.1.241
displayName (case-insensitive, any prefix allowed)
givenName (case-insensitive, any prefix allowed)
If none are present, Yoodli uses the email address as the display name. Once set, the display name is not automatically updated if the IdP later sends a different value.
You can optionally specify a display name attribute override in the SSO configuration if you want Yoodli to use a particular attribute for the user’s display name.
4. Set up SAML SSO
As part of Enterprise organization, admins can configure SAML SSO directly in the Yoodli admin view.
Step 1 – Open SSO settings
In Yoodli, go to the admin view.
Navigate to Org Settings > Access and SSO > SSO and Sign in.
Click: Manage
Step 2 – Set the display name
Enter a Display Name for this SSO (for example, TechNovate ID).
This is what end users will see as the button label, e.g. “Sign in with TechNovate ID.”
Click Save.
Step 3 – Configure your IdP
In the same SSO configuration page, you will see:
Service Provider Entity ID
SAML provider callback (SP callback URL)
Provide these values to your IdP (e.g., Okta, Entra ID) when setting up the Yoodli application.
From the IdP, collect the following:
IdP Entity ID
SSO URL (login URL)
Certificate (base64)
Alternatively, obtain a metadata XML file that contains these values.
Step 4 – Enter or import IdP details
Back in the Yoodli admin view:
Either paste the IdP Entity ID, SSO URL, and certificate into the fields,
Or click Import IdP XML and upload the metadata XML file.
Only these three items (IdP Entity ID, SSO URL, certificate) are read from the XML file. Any other fields in the XML are ignored.
Click Save again.
If all required information is present, the SSO configuration status changes to “Ready (unpublished)” and a Test URL is shown.
5. Test and publish SAML SSO
Test SSO
Copy the Test URL shown in the SSO configuration.
Open a new private/incognito browser window.
Paste the Test URL and follow the sign-in flow with your IdP.
Confirm that you are signed into Yoodli using SSO.
If the test fails, see Troubleshooting below.
Publish SSO
Once the test succeeds:
Return to the SSO configuration page.
Click Publish.
The status changes to “Published” and the SSO option becomes visible on the sign-in page (e.g., “Sign in with Acme SSO”). You can later Unpublish if you need to temporarily hide the SSO option.
6. Advanced SAML options
The SSO configuration page exposes several advanced options.
Direct jump to sign-in page
By default, Yoodli shows a “Sign in with <SSO name>” button on the sign-in/sign-up page when SSO is configured. Admins can enable Direct jump to sign-in page so that users go straight to the SSO sign-in page when they attempt to sign in, without choosing it from the list first.
Skip user confirmation / just-in-time provisioning
If enabled, users signing in from SSO are given membership in the org and its default user group by default.
You can control which users can access Yoodli by managing who is allowed to use the Yoodli SSO application in your IdP. If you instead rely on other mechanisms (such as invitations and SCIM integrations) to manage access and group membership, this option should be disabled.
Display name attribute override
You can enter an attribute name in the Display name override field if you want Yoodli to use a specific SAML attribute as the user’s display name (for example, fullName).
7. OIDC SSO
Yoodli also supports single sign-on via OpenID Connect (OIDC).
To set up OIDC SSO for your organization, please contact Yoodli support.
Once OIDC SSO is configured, org admins can:
View the OIDC SSO configuration,
Change the Display Name, and
Publish / Unpublish it.
Other parameters for OIDC SSO cannot be changed by admins.
8. SCIM and domain-based enrollment
Yoodli supports managing user membership and groups via SCIM integrations with compatible systems. The specification also notes that Yoodli can automatically enroll users into an org when they sign up with an email in a specific domain. Both of these require assistance from Yoodli support to configure.
If you’re interested in SCIM or domain-based auto-enrollment, contact your Yoodli account team or support.
9. Enforce specific sign-in options
If you don’t want to set up SSO but still want to provide a simplified sign-in experience, you can control which sign-in options appear for your organization.
Manage your feature access / sign-in options.
Choose which sign-in methods to allow (Email, Google, Microsoft).
At least one option must remain selected.
10. Troubleshooting
Below are documented failure cases and what to check.
“We are not able to let you access” (or generic sign-in failure)
Confirm that the SSO configuration status is Ready and Published.
Check that the NameID field in the SAML assertion contains a valid email address. If the IdP sends email only in another attribute, the sign-in will fail. This cannot be overridden.
Verify that the certificate is correctly base64-encoded and matches the one configured in your IdP.
Confirm that the Service Provider Entity ID and callback URL in your IdP match exactly what is shown in Yoodli.
User cannot sign in but others can
Check whether the user is assigned to the Yoodli application in your IdP.
Some IdPs (for example, Entra ID) display an error indicating the user is not assigned to the app.
Display name appears as email
This occurs if none of the supported display name attributes are present or mapped for the user.
Optionally configure a display name attribute override in the SSO settings to use a specific attribute.
If you continue to have issues after checking the above, contact [email protected] with:
A description of the error
Whether you’re using SAML or OIDC
A recent timestamp and affected user’s email
Any relevant error message or screenshot from your IdP’s sign-in page
Still need help?
Contact [email protected] or click the messenger at the bottom right to chat