Set up SSO
Create and enable an OIDC connection for your organization.
Configure SSO from Settings → Organization → Single sign-on.
| Who | Organization owner or admin |
| Applies to | Proliferate Cloud |
| Requirement | An OIDC application from your identity provider (Client ID, Client secret, Issuer URL) |
| Affects | The whole organization |
Create an OIDC application with your provider
Create the app in your identity provider and note the Client ID, Client secret, and Issuer URL. See the provider guides for Google, Okta, Entra ID, Auth0, and GitLab specifics.
Fill in the connection
| Field | What to enter |
|---|---|
| Display name | A label for this connection, e.g. Acme SSO. Shown on the sign-in button. |
| Allowed domains | Comma-separated email domains permitted to sign in, e.g. company.com, partner.com. Leave blank to allow any verified email. |
| OIDC issuer URL | Your provider's issuer, e.g. https://idp.example.com. Endpoints are auto-discovered from <issuer>/.well-known/openid-configuration. |
| OIDC client ID | The application's client ID. |
| OIDC client secret | The application's client secret. When editing later, leave blank to keep the saved secret. |
| OIDC scopes | Defaults to openid email profile. Add more only if you need extra claims. |
| Token auth method | Defaults to client_secret_basic; client_secret_post and none are also available. Match what your provider expects. |
Copy the redirect URI into your provider
The form shows a read-only Redirect URI with a copy button. Copy the exact value shown and register it verbatim in your provider's app as the callback / sign-in redirect URL. Do not retype or guess it — most providers reject a login if the redirect URI does not match character-for-character.
Save, then test, then enable
Save first. The connection starts in Draft. Test and Enable are blocked while the form has unsaved edits, so save before either.
Click Test to validate the provider's OIDC configuration and endpoints (it resolves the discovery document; it does not exchange credentials, check claims, or run a full sign-in). A successful test is recorded on the connection (there is no separate "Tested" status). Once it passes, click Enable — the status moves from Draft to Enabled. After enabling, complete a real pilot sign-in before inviting the broader team.
Test before you enable. A misconfigured connection that is enabled can break that sign-in path, though existing sessions and GitHub sign-in still work.
Statuses and management
Connection status is Draft (saved, never enabled), Enabled, or Disabled. From the same screen an admin can re-run Test, Disable (stop SSO sign-in without deleting the config; existing sessions are unaffected), Enable a disabled connection, or Delete it.
To switch providers, edit the same connection's fields rather than creating a second one.
Enabling SSO does not force members through it. SSO-only / required login is not supported today; GitHub sign-in and existing sessions remain available.