Skip to main content
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: 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: In production, the fixed addresses are these:

​
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

The guide of each provider lists the refusal messages and what to check in the console of the provider.