How It Works

This page explains how sign-in providers behave: which types exist, what users see on the sign-in page, how accounts are matched and created at sign-in, how identities are linked across providers, which restrictions apply, how sessions behave.

Each provider is independent: you can run several at once, enable or disable them individually, and let users pick how they sign in.

Provider Types

The Sign-In Experience

The sign-in page reflects your enabled providers:

• Each enabled identity provider appears as its own Sign in with button carrying the provider's display name, so users pick how they authenticate. When a single identity provider is the only thing enabled, its button is labelled just Sign In.
• When Email & Password sign-in is enabled, the page shows the email and password form with a Reset Password link for self-service password recovery.

What Happens at Sign-In

When a person authenticates through a provider, Qualytics resolves their identity in this order:

1. Known identity. If the identity is already linked to a Qualytics account, the person signs in to that account.
2. Matching email. If the identity is new but its email matches exactly one existing active account, Qualytics treats it as a request to link a new sign-in identity to that account. Whether the link happens automatically or waits for an administrator depends on the provider's linking settings (see Identity Linking below).
3. New user. If no account matches and Automatic user provisioning is enabled on the provider, a new account is created with the Member role and membership in the Public team. With provisioning off, sign-in is refused and the person is told that new account creation is not enabled for the provider.

Sign-in is also refused, before any of those steps, when the identity provider sends no email address for the person, or when the email matches more than one active account. Both cases ask the person to contact an administrator and are recorded in the sign-in log with the reason.

User Provisioning

Each OIDC and SAML provider has its own Automatic user provisioning setting (on by default). It lets eligible identities create Qualytics accounts on their first sign-in. Confirm the provider's email verification, domain restrictions, and group restrictions are appropriate for every user who could authenticate, or turn the setting off to admit only accounts that already exist.

On an OIDC provider with Require verified email turned on, an identity whose email the provider does not report as verified cannot create an account, in addition to being unable to link to an existing one.

Accounts can also be created independently of provisioning:

• By an administrator, through an email invitation (requires an enabled Email & Password provider).
• Ahead of time, through Directory Sync.

Identity Linking and Approvals

Three settings on each provider control whether an identity from that provider can be attached to an existing account with the same email:

While a link is pending, sign-in attempts through that provider are refused with a message that the link is awaiting administrator approval. After approval, the person simply signs in again. Rejected requests stay blocked, and because the Link approvals tab lists only pending requests, reversing a rejection is done through the API. See Review Link Approvals for the review flow.

A link is created automatically, without review, when linking is enabled and approval is not required. Require administrator approval is the setting that holds a link back for review, so leave it on for any provider you do not trust to be authoritative for each user's email address. Require verified email refuses the link outright instead of proposing it: nothing appears in the Link approvals tab, and the refusal is recorded in the sign-in log.

Access Restrictions

Each provider carries its own restrictions, evaluated at every sign-in:

To keep administrators from locking themselves out, Qualytics refuses restriction changes that would exclude the administrator making them: you cannot remove your own email domain from the allowed domains, remove all of your own groups from the allowed groups, disable the provider your current session signed in with, or require verified email when your own identity does not report one.

Google Workspace Groups

Google's sign-in does not include group membership, so Google Workspace providers fetch it from the Google Workspace Directory instead:

• On an OIDC provider whose issuer is Google, enable Fetch Google Workspace groups. The provider then needs a one-time authorization by a Google Workspace administrator, granting read-only access to Users and Groups. Users are never asked for Directory access themselves.
• The provider cannot be enabled until the authorization is completed. The provider form shows the authorization status, who authorized it, and lets you verify, reauthorize, or disconnect the grant.
• At sign-in, the person's Workspace groups are retrieved and used like any other provider groups: for the Allowed Groups restriction and, when Sync groups to Teams is on for the provider, for Team mapping.

Sessions

• Session Duration is set per provider (480 minutes by default). Activity extends a session, up to a deployment-wide maximum lifetime (24 hours by default), after which the person signs in again.
• Sessions end early when trust changes: disabling a provider, editing its security-sensitive settings (credentials, certificates, tightened restrictions), resetting a password, deactivating a user, or rejecting a pending link all end the affected sessions. The platform warns you with a confirmation dialog before a change that signs users out.
• For OIDC providers configured for offline access, Qualytics also reconfirms the session with the identity provider as the session is extended, so a user disabled there loses access without waiting for the session to expire. See Staying Signed In below.

Staying Signed In

A session lasts for its configured Session Duration, extended by activity up to the deployment-wide maximum lifetime. That holds whichever provider the person signed in with, and it does not depend on the access the identity provider granted at sign-in. That access typically expires after about an hour, and its expiry does not end the session.

What that access buys is confirmation, not time. While Qualytics still holds usable access, each extension of the session is an opportunity to ask the identity provider whether the account is still in good standing, and an answer of no signs the person out immediately. When the access has expired and cannot be renewed, or the identity provider cannot be reached, the session simply continues without that confirmation, carried by the checks Qualytics performs itself on every request: the provider is still enabled, the account is still active, the sign-in link is still approved.

Adding the offline_access scope to an OIDC provider is what keeps the confirmation running. The identity provider then issues Qualytics a refresh token, which silently renews that access for the life of the session. With the scope, an account disabled at the identity provider is signed out at the next session extension. Without it, that person keeps working until the session reaches the deployment-wide maximum lifetime, or until they next sign in. The scope is configured once on the provider and applies to all of its users. Each person starts benefiting at their next sign-in, and removing the scope likewise stops the renewal at each person's next sign-in.

Two conditions have to be met for the confirmation to work. The provider's UserInfo Endpoint must be set, because that is the endpoint Qualytics checks the account against; with that field empty, sessions run their full duration unconfirmed whichever scopes are configured. The identity provider must also permit the scope in the application registration you created for Qualytics, since it only issues a refresh token when it accepts the request.

The identity provider can also withdraw the renewal. An administrator revoking the application's access, or the person changing their password at the identity provider, makes the next renewal fail; because that is the provider explicitly refusing the credential, Qualytics treats it as a revocation and the person signs in again. An identity provider that is merely unreachable (an outage, a network problem, a maintenance window) is not treated that way. Those sessions continue, and confirmation resumes on its own once the provider answers again.

Google Workspace does not use the standard offline_access scope; Google grants offline access through its own mechanism. Add the scope to the provider anyway, and Qualytics translates the request into the form Google expects. Because Google does not advertise the scope, the provider Test flags it with a warning, which is expected and does not block saving. The first sign-in after the scope is added may show Google's consent screen once; later sign-ins are silent. Google reports a suspended or deleted Workspace account by refusing the renewal, so this is the configuration that signs those accounts out during their session.

SAML and Email & Password sessions do not depend on the identity provider after sign-in, so they are extended on activity with nothing to configure, and none of this applies to them.

Safely Changing Sign-In Providers

Create and test a provider before enabling it. A disabled provider is not offered on the sign-in page. Once enabled, it is available immediately, and users who already have accounts follow its identity linking policy when signing in through it for the first time.

Complete a real sign-in through the new provider in a separate browser session, including with an Admin account. Provider diagnostics cannot confirm the account's role and Team memberships. To disable a previous provider, sign in as an Admin through one you intend to keep: you cannot disable the provider used by your current session or the last enabled customer sign-in provider.

Disabling a provider ends its active sessions. Users can sign in again through another enabled provider if its access restrictions and identity linking policy permit them.

The Other Access Tabs

Provider management sits alongside three related tabs on the Access settings page, all Admin-only:

• Link approvals: review requests to link a new sign-in identity to an existing account. See Review Link Approvals.
• Invitations: invite new users by email and track the invitations you sent. Appears when an Email & Password provider is enabled. See Invite a User.
• Log: the audit trail of sign-in activity and provider configuration changes. See View the Sign-In Log.

Audit Trail

Provider configuration changes (creation, edits with before-and-after values, deletion), sign-in successes and failures, lockouts, invitations, link approvals and rejections, and denied sign-ins (for example, an unauthorized email domain or a deactivated account) are all recorded and reviewable in the Log tab. See View the Sign-In Log.