Single sign-on (SSO) is an authentication method that enables users to securely authenticate with multiple applications and websites by using just one set of credentials. It asks the users to enter their credentials to log in to an application only once.
Single Sign-On (SSO) works by creating a trust between two systems: one that provides the identity (called the identity provider, like Azure) and one that provides the service (called the service provider, like an app or website).
This trust is usually set up by exchanging a certificate between the two systems. The certificate helps ensure that any information shared about a user's identity (like their email or username) is secure and comes from a trusted source.
In SSO, this identity information is sent in the form of tokens. These tokens include details about the user and are used to verify their identity, allowing them to log in without needing to enter credentials multiple times.
The login flow usually looks like this:
- A user browses to the application or website they want access to, aka, the Service Provider.
- The Service Provider sends a token that contains some information about the user, like their email address, to the SSO system, aka, the Identity Provider, as part of a request to authenticate the user.
- The Identity Provider first checks to see whether the user has already been authenticated, in which case it will grant the user access to the Service Provider application (and skip to step 5.)
- If the user hasn’t logged in, they will be prompted to do so by providing the credentials required by the Identity Provider. This could simply be a username and password, or it might include some other form of authentication like a One-Time Password (OTP).
- Once the Identity Provider validates the credentials provided, it will send a token back to the Service Provider confirming a successful authentication.
- This token is passed through the user’s browser to the Service Provider.
- The token that is received by the Service Provider is validated according to the trust relationship that was set up between the Service Provider and the Identity Provider during the initial configuration.
- The user is granted access to the Service Provider.
How to configure SSOs in Quixy?
For example, a parent company might use Azure for logging in, while its subsidiaries use Okta or Google. By configuring multiple login methods, each part of the organization can use the most suitable method, ensuring both security and convenience. Users are assigned the correct login based on their department or role, improving security across the organization.
- Click Admin Menu -> Preferences -> Single Sign On(SSO).
- On the Single Sign On page, select the identity provider among Azure, Okta, Auth0,Google, AD, or LDAP that you use for your organization to configure SSO.
- Select the provider type between OIDC and SAML.
- The options shown in the image below are the same for any type of identity provider that you select, and each field contains help text that explains what information is needed (The configuration process for AD/LDAP is outlined below.)
Avoid disrupting the configurations when disabling or reestablishing SSO connections. Simply toggle the switch to easily turn on or off the specific SSO you wish to disable.
AD and LDAP Configuration
AD and LDAP can be configured as new SSO options, alongside other providers such as Azure, Okta, Google, and Auth0. Organizations can now set up AD or LDAP independently, without requiring backend support. AD/LDAP can support large organizations with complex hierarchies, making it easier to manage diverse login needs across departments or subsidiaries.
Many industries require stringent access controls. Using AD/LDAP as an SSO can help meet compliance requirements by providing secure, centralized user access management.