SSO Management
When using tenants in Descope, it's common to connect external IdPs and associate them to your tenants as well. These are what we call SSO Tenants, and can be managed a couple of different ways.
Overview of SSO Management
With Descope, you can configure tenant-specific SSO, manage attributes and group mappings, and provide a seamless authentication experience across all tenant applications. Each tenant is allowed to integrate with their preferred identity provider (IdP), such as Okta, Azure AD, or Google Workspace.
Descope’s tenant SSO features include self-service configuration, testing of SSO connections, and the ability to map custom claims to user roles, groups, or other attributes.
Managing SSO Settings
These SSO settings can be managed different ways, depending on your preference.
Descope Console
You can modify your Tenant settings and attributes, as well as create and delete them, all from the Tenants page in the Descope Console.
Management SDKs
Visit our Management SSO section to see all of the various ways you can manage SSO authentication in your backend with our Management SDKs.
Self Service SSO Configuration
Tenant admins can also configure their own SSO, using our self-service SSO configuration widget. If you would like to learn more about how to use this widget, you can visit our section on this here
Account Recovery Login ID Flow
By default, once the Tenant Admin logs in successfully via SSO, their original login ID added by the Descoper (Descope Console admin) will be replaced with the SSO-specific one.
This can be controlled via a flag in the Descope Console, under Authentication Methods -> SSO -> Convert existing user to SSO-only after successful SSO login. It is enabled by default to essentially force SSO-based login for the Tenant Admin user in the future.
However, suppose you're hosting the sso-config flow above in your application, and a Tenant Admin accidentally changes the SSO configuration; this can prevent them from logging in and changing the SSO Configuration back to the correct settings.
Therefore, if SSO login is rendered inoperational as a result of this, you can add the ability to verify and merge an additional email login ID to the user by including the Update User action in the flow like so:
When you add an Update User / Email action to the flow, you can verify and re-add their original email as a login ID. You can also do an Update User / OAuth action to add a social login as an additional login ID.
You will need to make sure you select Add to Login IDs under the Update User action in order for the login IDs to be merged:
Other Relevant Documentation
Here are links to some other guides that are relevant to effectively managing tenant-based SSO.