OIDC SSO setup

This guide walks an identity provider (IdP) administrator through adding Conflixis as an OpenID Connect (OIDC) application in your IdP. Once configured, you'll send a small set of values to your Conflixis contact, who will finish the connection on the Conflixis side.

The integration uses OpenID Connect (OIDC), not SAML. Any standards- compliant OIDC provider works, including:

• Okta (Workforce Identity / Customer Identity)
• Auth0
• Ping Identity (PingOne, PingFederate)
• Keycloak
• ForgeRock
• OneLogin
• JumpCloud

If your provider supports OIDC's Authorization Code flow and publishes a standard discovery document, it will work. Google Workspace is covered by its own dedicated flow because Conflixis ships a pre-built integration for it.

Step 1 — Create an OIDC application in your IdP

In your IdP's admin console, create a new application with the following settings. The labels vary by vendor — the underlying OIDC values are the same.

| Setting | Value | | ------- | ----- | | Application type | Web application (server-side, confidential client) | | Grant type | Authorization Code | | Client authentication | Client secret (basic or POST) | | Sign-in redirect URI | https://conflixis-web.firebaseapp.com/__/auth/handler (production; see below) | | Sign-out redirect URI | Leave blank | | Token endpoint auth method | client_secret_basic or client_secret_post |

The Sign-in redirect URI for the Conflixis production sign-in app is:

https://conflixis-web.firebaseapp.com/__/auth/handler

Use this value unless your Conflixis contact has onboarded your tenant to a different environment (e.g. a preview environment for pre-launch testing), in which case they'll provide the alternative URI.

Vendor-specific notes

• Okta — Choose Applications → Create App Integration → OIDC - OpenID Connect → Web Application. Set the App integration name to Conflixis.
• Auth0 — Create a Regular Web Application. Under Settings, copy the Domain for use as the issuer (https://<your-tenant>.auth0.com/).
• Ping / PingOne — Create an OIDC Web App connection. Use client_secret_basic for token auth.
• Keycloak — Create a confidential client under your realm. The issuer is https://<host>/realms/<realm>.

Step 2 — Capture the values to send Conflixis

After saving the application you'll see a page with the client credentials. Conflixis needs four pieces of information:

| Item | Where to find it | | ---- | ---------------- | | Client ID | The application's Client ID (sometimes called Application ID). | | Client secret | The application's Client secret. Send this through a secure channel (e.g. 1Password share link) — do not email it. | | Issuer URL | The base URL of your IdP's OIDC authorization server. Examples: https://acme.okta.com, https://acme.auth0.com/, https://auth.example.com/realms/employees. The issuer must serve a valid discovery document at <issuer>/.well-known/openid-configuration. | | Email domains | The work email domains your users sign in with (e.g. acme.com, acme.org). Conflixis routes sign-in attempts from these domains to your IdP. |

Send these to your Conflixis contact. We'll confirm once your tenant is wired up on our side.

Step 3 — Required scopes and claims

The Conflixis app requests three standard OIDC scopes:

• openid
• email
• profile

From the resulting ID token Conflixis reads:

• Email (email) — used to match the user to their pre-provisioned Conflixis account.
• Name (name / given_name / family_name) — used for display.
• Subject identifier (sub) — used to recognise the same identity on subsequent sign-ins.

Conflixis does not read group memberships and does not request any custom claims. Roles inside the Conflixis admin app are managed within Conflixis itself.

Step 4 — Provisioning your users

Conflixis uses admin pre-provisioning: users must exist in the Conflixis admin app before they can sign in. SSO sign-in does not auto-create accounts — it links the IdP identity to a Conflixis user record that already exists.

• Initial setup — your Conflixis contact will create the first set of admin users on your team. Send them the list of email addresses that should have admin access at go-live.
• Ongoing additions — once those initial admins can sign in via SSO, they can add additional team members directly from the admin interface in the Conflixis app. No further help from Conflixis is required for day-to-day user management.

If a user signs in via your IdP and there is no matching Conflixis user with their email, sign-in is rejected with a message asking them to contact their Conflixis administrator.

Step 5 — Validate the integration

Once Conflixis confirms your tenant is wired up:

1. Ask one of your administrators (already pre-provisioned in Conflixis) to visit https://client.conflixis.com/.
2. Type their work email in the email field. The page will detect that your domain is configured for SSO and surface a Continue with company SSO button.
3. Clicking it redirects to your IdP, the user authenticates, and they land back in the Conflixis admin app.

If sign-in fails, capture:

• The exact error message shown to the user.
• The time of the attempt and the user's email.
• The relevant entry from your IdP's system log (for example, Reports → System Log in Okta, or Monitoring → Logs in Auth0).

Send these to your Conflixis contact for diagnosis.

Optional — enforcing SSO

By default, users in your organization can sign in via your IdP or via email/password if they have a Conflixis password set. Once your team has fully migrated to SSO, a Conflixis administrator at your organization can flip a per-org toggle that requires SSO for users on your configured email domains. After that, password sign-in is disabled for those users; only Conflixis super-admins (Conflixis staff) retain a break-glass password path.