Using CertivantSettingsIdentity & SSO

Identity & SSO

Configure single sign-on for your Certivant organization using Google, Microsoft, GitHub, SAML 2.0, or OIDC so your team authenticates with their existing corporate identity.

Who can do this:Org ownerOrg admin

What it does

Single sign-on (SSO) lets your team members sign into Certivant with their existing corporate identity — Google Workspace, Microsoft 365, Okta, OneLogin, etc. — instead of remembering yet another password. Same security boundary as your IdP: when you offboard someone there, they lose Certivant access too.

Three SSO modes:

  1. Social providers — Google, Microsoft, GitHub. One-click sign-in for individual users. Each user clicks "Sign in with Google" once and we link them to their existing org-member record by email.
  2. SAML 2.0 — for enterprise IdPs (Okta, OneLogin, Azure AD, ADFS). Set up an enterprise app on their side, paste the metadata into Certivant, done.
  3. OIDC — OpenID Connect for IdPs that prefer it over SAML (Auth0, Keycloak, modern Okta tenants).

Where it lives

Settings → Identity & SSO in the left sidebar.

Social providers (the easy mode)

These are configured by your super admin at the platform level. You don't configure them per-organization — they're either on or off across the whole deploy. If they're on, your team members see "Sign in with Google" / "Sign in with Microsoft" / "Sign in with GitHub" buttons on the login page.

When a teammate signs in with a social provider:

  1. The IdP returns their verified email.
  2. Certivant matches that email to the member record you previously invited.
  3. They land in your organization, no extra steps.

If their IdP email doesn't match any invited member, they get an "Account not found — ask your admin to invite you" message.

If everyone in your org uses Google Workspace, ask your super admin to enable Google SSO and disable email-password sign-in. One fewer password to manage, one fewer phishing surface.

SAML 2.0

For mid/large enterprises with an IdP that already manages app provisioning.

On Certivant: open Identity & SSO

Settings → Identity & SSO → SAML. Toggle Enable SAML on. The screen reveals:

  • Your ACS URL (Assertion Consumer Service): https://app.certivant.com/api/auth/saml/callback/{your-org-id}. Copy.
  • Your Entity ID (SP entity id): urn:certivant:org:{your-org-id}. Copy.
  • Upload IdP metadata: where you'll paste the XML from your IdP after step 2.

On your IdP: create a new SAML app for Certivant

Different IdPs have different wording, but the fields are universal:

  • SP entity id — paste the Entity ID from step 1.
  • ACS / Reply URL — paste the ACS URL from step 1.
  • Name ID format — EmailAddress (we match members by email).
  • Attribute statements (optional but useful):
    • firstName, lastName — used to pre-fill the member profile.
    • groups — list of group memberships. Map to Certivant roles via the dropdown on the IdP side.

Download the IdP metadata XML.

Back on Certivant: upload the metadata

Paste the XML into the Upload IdP metadata field on the Identity & SSO page. Save.

Test

Open a new private window. Click Sign in with SAML, enter your email. You should be redirected to your IdP, log in, and bounce back to your Certivant org.

(Optional) Restrict to SAML

Once you've confirmed it works, you can require SAML for every member of your org: Settings → Identity & SSO → Require SSO toggle on. Email-password sign-in still works for your org owner (escape hatch) but is blocked for everyone else.

Just-in-time (JIT) provisioning

When a new IdP user signs in for the first time, Certivant can:

  • Block — only previously-invited members get in.
  • Auto-create as Member — any IdP user with a valid SAML response becomes an org member automatically.
  • Auto-create with role from group claim — read the groups attribute from the SAML response and assign Owner / Admin / Member based on a mapping you configure.

Pick under Settings → Identity & SSO → SAML → New-user provisioning. JIT is convenient but reduces your control — if your IdP is configured to send EVERY employee, you'll auto-onboard everyone whether they need Certivant or not.

OIDC

OIDC works similarly but with simpler JSON instead of XML.

Settings → Identity & SSO → OIDC. Toggle on.

Copy the Redirect URI: https://app.certivant.com/api/auth/oidc/callback/{your-org-id}.

Create an OIDC application on your IdP. Paste the redirect URI. Configure scopes: openid, email, profile, plus groups if you want role-mapping.

On Certivant: paste the IdP's Issuer URL, Client ID, and Client Secret.

Save. Test from a private window via Sign in with SSO.

Removing SSO

Toggle the relevant provider off under Settings → Identity & SSO. Already-signed-in members stay logged in until their session expires; their next sign-in must use email-password (or another enabled provider).

If you previously required SSO and now want to drop it, also toggle Require SSO off so members can fall back to email-password.

Troubleshooting

"SSO not configured for this organization"

You toggled the provider on but the configuration is incomplete. Open the SAML/OIDC section and check that every required field is filled.

"Invalid SAML response" / "Invalid OIDC token"

Common causes:

  • Clock skew between your IdP and our servers. Most IdPs ship NTP-synced; your own deploy might not.
  • Wrong Entity ID / Audience on the IdP side. Double-check the Certivant-displayed values match what's in your IdP app.
  • Signature mismatch — you regenerated certificates on the IdP without re-uploading metadata to Certivant. Re-paste the latest metadata.

"Account not found"

The IdP returned an email that doesn't match any invited member. Either:

  • Invite the user from Settings → Members first (with the same email the IdP returns).
  • Enable JIT provisioning to auto-create.

My org owner can't sign in via SAML

By design — the owner can always sign in with email-password, even when Require SSO is on, so you have an escape hatch if SSO breaks. If even that fails, contact your super admin to fix from the platform side.