SSO — single sign-on with OIDC or SAML

Single sign-on lets your team log into Wilow through your existing identity provider — Microsoft Entra, Okta, Google Workspace, Auth0, OneLogin, Keycloak, anything that speaks OIDC or SAML 2.0. After it's wired up, your admins click Sign in with SSO, get bounced to your IdP, and land in Wilow with no Wilow-specific password to manage.

When to enable SSO

Turn this on if any of these is true:

  • Your IT/security policy requires identity-provider-mediated access for SaaS tools.
  • You're past two or three Wilow admins and rotating passwords manually is becoming busywork.
  • You want central revocation — when someone leaves the company, removing them in your IdP should remove them from Wilow, full stop.

Skip it if you're a single-operator workspace; the email-and-password flow is fine until the team grows.

How to enable it

  1. Admin → Settings → SSO.
  2. Pick the protocol: OIDC or SAML 2.0. Both are first-class — choose whichever your IdP makes easier.
  3. In your IdP, create a new app for Wilow. The page shows the Redirect URI (OIDC) or ACS URL + Entity ID (SAML) you need to paste over there — copy them as-is, they're environment-specific.
  4. Paste the IdP-side values back into Wilow:
    • OIDC — Issuer URL, Client ID, Client Secret.
    • SAML — SSO Entry Point (login URL), IdP Issuer (entityID), the IdP signing certificate (paste the full PEM block, including the -----BEGIN CERTIFICATE----- lines), and optionally the email attribute name if your IdP uses something other than EmailAddress.
  5. Set Allowed email domains — a comma-separated list of domains your IdP signs accounts for (acme.com, acme.co.uk). Users whose IdP-asserted email doesn't match are rejected at callback. Leave blank to accept any domain, but only do that on a single-tenant IdP.
  6. Save. The IdP test happens on the first real login attempt.

Require SSO (enforce)

The Enforce SSO toggle is the security-policy lever: when it's on, password login is disabled for your workspace, and members must come in through your IdP. Without it, both paths stay open — handy while you're testing the setup.

Don't enforce until you've signed in successfully at least once. If the IdP config is wrong and enforcement is on, no one — including you — can get into your workspace. We'll un-stick you over email if it happens, but it's faster to validate first.

What "JIT provisioning" means here

The first time a new user lands at our callback with a valid IdP assertion (and an allowed domain), we create their Wilow membership automatically. No invite, no manual add. The opposite is also true: revoke in your IdP, they can't log back in. You don't have to also remove them from Wilow, but you can if you want their row to disappear from the Team list.

Editing secrets

Secret-like fields — the OIDC client secret and the SAML signing certificate — are write-only. When you re-open the config, the page shows "set" rather than the value. Leave the field blank to keep the stored secret; paste a new value to rotate.

Common questions

  • Can I require SSO? Yes — toggle Enforce SSO on. Validate the IdP login works first.
  • Can I use both OIDC and SAML? No — one IdP per workspace. Switch the protocol on the same page; you'll need to re-paste the secrets/cert for the new shape.
  • What happens to existing password users? Their passwords still work until you enforce SSO. After enforcement, only the SSO path works.
  • Do I have to invite users individually? No. JIT provisioning creates them on first IdP-mediated login, as long as the asserted email is in your allowed domain list.
  • Who can configure SSO? Workspace admins. See team and permissions.
  • My IdP doesn't show login — what now? Check the troubleshooting guide, then forward the IdP-side error message to us.

See also team and permissions for member management, account for personal-profile changes, and audit log for who-signed-in-when.

Where to find us

Stuck? Email [email protected]. Include your IdP product name and a paste of the error message from the IdP side — that's usually enough for us to spot the misconfiguration.