What it’s for
SSO lets your team sign in to the web dashboard with your company’s identity provider: Google Workspace, Microsoft Entra ID, or any OIDC provider. No separate password, with MFA and access policies inherited from your IdP.
SSO covers manager sign-in to the dashboard. Collaborators still sign in to the desktop agent with an email OTP, and can be synced via SCIM. See SCIM Provisioning.
How it works
qlture acts as the Service Provider over OpenID Connect (OIDC); your IdP handles authentication. The flow is the standard one:
- The manager opens the dashboard and clicks Sign in with company SSO.
- They are redirected to your IdP and authenticate there (with the MFA you already use).
- The IdP returns the identity token to qlture at the Redirect URI.
- qlture validates it, matches the user by email, and issues the session.
sequenceDiagram
participant G as Manager
participant Q as qlture
participant I as Your IdP
G->>Q: Sign in with company SSO
Q->>I: Redirect to authenticate
I->>I: Login + MFA
I-->>Q: Identity token (Redirect URI)
Q->>Q: Validate and match by email
Q-->>G: Session issued
SSO is configured per tenant, under Settings → SSO (TENANT_ADMIN access).
Configure
The screen has two sides: on the right, what you take to your provider; on the left, the credentials you bring back.
1. Register the app with your provider
Copy the Redirect URI shown in the dashboard and register it as an authorized redirect URI in your provider’s OAuth/OIDC application. This is how the login flow returns to qlture.
2. Paste the credentials
Choose the provider in the selector (Google Workspace, Microsoft Entra, or Other (OIDC)) and fill in:
| Field | What it is |
|---|---|
| Issuer (provider URL) | The base URL of the OIDC provider. For Google, exactly https://accounts.google.com |
| Client ID | The OAuth client ID generated at the provider |
| Client Secret | The client secret key (write-only — leave blank to keep the current one) |
| Email domains | Company domains that use this SSO, comma-separated |
Click Save. When SSO is active, the dashboard shows “SSO enabled — your team can now sign in with the SSO button.”
Just-in-time provisioning (JIT)
The Create user on first sign-in option controls just-in-time provisioning: if the email coming in through SSO doesn’t yet exist in the tenant, qlture creates the account automatically as a collaborator on the first login. Turn it off if you’d rather only allow users who are already provisioned (by invite or SCIM).
By provider
Google Workspace — in Google Cloud Console → APIs & Services → Credentials, create an OAuth client ID of type “Web application”, add the Redirect URI, and copy the Client ID (ends in .apps.googleusercontent.com) and the Client Secret (starts with GOCSPX-). Issuer = https://accounts.google.com.
Microsoft Entra ID — register an app under Entra → App registrations, add the Redirect URI as a Web platform, create a client secret, and use your tenant’s Issuer.
Other (OIDC) — any compatible provider: supply the Issuer (which exposes .well-known/openid-configuration), Client ID, and Secret.
Best practices
- Restrict by domain. Only emails from the registered domains sign in through SSO — never allow domains you don’t control.
- MFA at the IdP. The second factor lives at your provider; keep it mandatory there.
- Lifecycle via SCIM. If you use SCIM, let SCIM create and deactivate accounts and use SSO only to authenticate. That way, offboarding at the IdP genuinely cuts off access.
Related
- SCIM Provisioning — sync your user base automatically.
- Getting started — roles and the authentication model.
