> ## Documentation Index > Fetch the complete documentation index at: https://developers.useqx.com/llms.txt > Use this file to discover all available pages before exploring further. # SSO login > How an organization connects the identity provider of the company to QX: the tested providers, what holds for all of them, and what to do when something goes wrong. This guide is for the IT team and for the owner of the organization in QX. It shows what holds for every identity provider. The guide of each provider shows the steps in its console. ## The providers that QX tests QX tests five identity providers. Each one has a guide: | Provider | Guide | User provisioning | | - | - | - | | JumpCloud | [SSO login with JumpCloud](/en/sso-jumpcloud) | Yes | | Google Workspace | [SSO login with Google Workspace](/en/sso-google-workspace) | No | | Microsoft Entra ID | [SSO login with Microsoft Entra ID](/en/sso-entra-id) | Yes | | Okta | [SSO login with Okta](/en/sso-okta) | Yes | | OneLogin | [SSO login with OneLogin](/en/sso-onelogin) | Yes | QX does not offer SAML. A provider outside the list does not show in the provider choice. ## What holds for every provider * The person signs in to QX through the SSO login, with the OIDC protocol. QX uses the authorization code flow with PKCE (S256). QX never sees the password. * QX asks for the scopes `openid`, `email` and `profile`. Without the e-mail, QX refuses each login. When the owner group sets the role, Okta and OneLogin also get the `groups` scope. * The QX app at the provider has a client ID and a client secret. The app authenticates QX at the token endpoint with `client_secret_basic` or `client_secret_post`. The owner chooses the same method in **Client authentication**, in QX. * User provisioning uses the SCIM 2.0 protocol. QX receives only users. The groups stay at the provider. Google Workspace sends no provisioning to QX. * QX knows the person by the identifier that the provider sends at the login. User provisioning sends the same identifier as `externalId`. The guide of each provider names that identifier. The owner sees the QX addresses in **Settings › SSO**, in the **Addresses for the identity provider** box: | QX address | What it is for | | - | - | | Login URL | Opens QX from the portal of the provider. It shows after the owner saves the SSO connection. | | Redirect URI | The provider sends the person back to this address after the login. | | User provisioning base URL | The provider calls this address to create, update and deactivate users. | In production, the fixed addresses are these: ```text theme={null} https://app.useqx.com/sso/callback https://app.useqx.com/scim/v2 ``` ## The provider choice The owner opens **Settings › SSO**, clicks **Configure SSO connection**, chooses the provider and clicks **Continue**. The form shows only the fields of that provider: * **Identity provider address**: the address that the provider uses as the issuer of the tokens. QX checks the format of each provider. In Microsoft Entra ID, the address carries the tenant ID. * **Company domain**: only in Google Workspace. QX accepts only a person who signs in with an account of this domain. * **Client ID**, **Client secret** and **Client authentication**. * **Two-step verification** and **SSO session duration**. * **Role of the people** and the e-mail options that the provider allows. The provider, the provider address and the domain do not change after the owner saves the connection. These values decide who can sign in to the organization. To change the provider, the tenant or the region, the owner removes the connection and configures a new one. A new client ID or a new **Client authentication** needs the SSO login disabled and asks for a new login test. The owner makes the change in this order: 1. If required SSO is on, click **Turn off required SSO**. 2. Click **Disable SSO login**. All sessions that started with SSO end, including the session of the owner. The owner signs in again with the password, or creates a password with **Forgot your password?**. 3. Click **Edit SSO connection**, change the value and click **Save SSO connection**. 4. Click **Test login**. 5. Click **Enable SSO login**. 6. If required SSO was on, click **Turn on required SSO**. ## The role of the people * **Set in QX** is the default. A new person signs in as an operator, and the owner changes the role in **Users**. * **Set by the owner group**: QX reads the `groups` claim at each SSO login. A person in the group signs in as an owner, and the other people sign in as operators. The role is read-only in **Users**. Google Workspace does not have this option, because the Google token carries no groups. The group gives the owner role only to a person that user provisioning or the login test bound. The group never takes the role from the last active owner of the organization. ## Two-step verification The option of the SSO connection applies when the organization requires two-step verification. A change of the option ends the sessions opened with SSO. * **Through the provider**: QX accepts the SSO login only when the token proves the second factor. In JumpCloud and Microsoft Entra ID, the `amr` claim must hold `mfa`, or a possession method (`otp`, `hwk`, `swk`, `sms`, `tel` or `sc`) together with the password, a PIN or biometrics. A single method does not pass. In Okta, QX asks for `acr_values=urn:okta:loa:2fa:any` and accepts only an `acr` equal to that value. * **Through the QX authenticator app**: after the login at the provider, the person types the code of the QX authenticator app. At the first login, the person sets up the app. The person has 15 minutes to finish. It is the only option in Google Workspace and OneLogin. QX never accepts the second factor without proof. Before a sensitive act, the identity confirmation also asks for a proof. QX asks for a new login at the provider when the provider allows it. In Google Workspace and OneLogin, or when the token does not say the time of the login, QX asks for the code of the authenticator app. ## Session duration The owner chooses the SSO session duration, from 1 to 8 hours. The default is 8 hours. After this time, the person signs in again through the provider. A shorter time also shortens the open sessions, counted from the login. A longer time applies to the next logins only. Without user provisioning, a person that the provider deactivates keeps the open QX session until the end of the time. In Google Workspace, choose a short time. ## Remove the SSO connection The owner removes the connection in **Settings › SSO**, in the **Remove SSO connection** box. The removal has these effects: * The sessions opened with SSO end, including the session of the owner. * SSO login and required SSO stop. People sign in with a password. * QX deletes the external identities and the provisioning keys. The provider stops creating and deactivating users in QX. * The users stay in QX. A person who only signed in with SSO creates a password with **Forgot your password?** on the login page. After the removal, the owner configures a new connection, with another login URL. ## When something goes wrong | Situation | What to do | | - | - | | The provider is down and required SSO is on | An owner with an open session clicks **Turn off required SSO**. With no owner session, QX support turns the rule off and records the reason. A person without a password uses **Forgot your password?**. | | The connection is wrong, or the company changes the provider, the tenant or the region | The owner removes the connection and configures a new one. | | No owner can sign in | QX support removes the connection and records the reason. Then the owner signs in with a password. | | The person lost the authenticator app | Another owner or QX support resets the second factor. When the organization requires two-step verification and the connection uses **Through the QX authenticator app**, the person sets up a new app at the next SSO login. In the other cases, the person sets up the app in **Account security**. | | The SSO tab says that QX changed the provider settings | The owner runs the login test again. The SSO login keeps working. | | The access of everyone must end now | The owner lowers the SSO session duration, or disables the SSO login. | The guide of each provider lists the refusal messages and what to check in the console of the provider. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.