Skip to content
Faldaro
All guides

Single sign-on

Members sign in through your own identity provider over OIDC. Your directory decides who gets in, your policies decide what they prove, and a session your provider opens can only ever act in your organisation.

What you need

An OIDC application in your identity provider — Entra ID, Okta, Google Workspace, Auth0, Keycloak and anything else that speaks standard OIDC discovery. From it you need three things: the issuer URL, a client id and a client secret.

Your Faldaro operator supplies one thing in return: the redirect URI to register in that application. Ask for it before you start; the configuration page shows the sign-in link once SSO is enabled.

Single sign-on is an Enterprise capability, and the identity-provider host must be allowed by the deployment — a deliberate operator step, so that no organisation can point this server at an arbitrary address on its own.

Setting it up

  1. In your identity provider, create an OIDC web application and register the redirect URI your operator gave you. Request the openid and email scopes.
  2. In Faldaro, open Settings → Single sign-on and enter the issuer URL, client id and client secret. Requires organization:write.
  3. Save with Enabled ticked. The page then shows the sign-in link to distribute — members can also use Use single sign-on on the sign-in page and enter your organisation's short name.

The issuer must be an https URL with no query or fragment; a trailing slash is trimmed for you. The client secret is write-only: it is stored, used for the sign-in exchange, and never shown again — leave the field blank when editing to keep the one already saved.

Who can sign in

Someone signing in through your provider must already have a Faldaro account with that email address, and must already be a member of your organisation. There is no automatic account creation: an address your provider asserts that matches no member is refused, not provisioned. Invite people the normal way; SSO governs how they authenticate, not whether they exist.

That is a deliberate choice rather than a missing feature — auto-creating members on a directory's word raises real questions (which role, counted against which seats, deactivated when) that deserve a decision rather than a default.

The session your provider opens

A session established through your identity provider is scoped to your organisation and the organisations beneath it, and stays scoped for its whole life — including across every silent renewal.

This matters when a person belongs to more than one organisation on Faldaro. Your provider is authoritative for your organisation; it is not authoritative for a different company that the same person also works with. So an SSO session cannot see or switch into their other memberships, and an administrator of your identity provider cannot mint access to somebody else's tenant by asserting an address. The same person signing in with a password still sees everywhere they belong.

Multi-factor, and what SSO delegates

Faldaro does not second-guess your provider. Whatever it enforces at sign-in — MFA, device posture, conditional access, IP restrictions — is what gates entry, and Faldaro trusts the result. This is usually the point of adopting SSO: the controls live in one place, applied to every application at once.

When sign-in fails

Every failure returns to the sign-in page with a single, undifferentiated message. That is deliberate: a stranger probing the endpoint learns nothing about which organisations exist, which have SSO, or which addresses have accounts. Administrators diagnosing a real problem should check, in this order:

  • The redirect URI registered in the provider matches the one your operator gave you, exactly.
  • The issuer URL is the provider's own issuer — its discovery document must agree.
  • The client secret is current (rotating it in the provider means re-entering it here).
  • The person has a Faldaro account with that address, and is a member of your organisation.
  • The deployment allows your provider's host — ask your operator.

Turning Enabled off stops new SSO sign-ins immediately, including any that are mid-flight. Password and passkey sign-in continue to work throughout: enabling SSO adds a way in, it does not remove the others.