Skip to content

New: a hosted MCP server. Point Claude at your intake desk. Read more

Faldaro
All docs

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 organization.

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 organization 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 organization'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 organization. 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.

Someone who also belongs to another organization on Faldaro needs one thing more: their address's domain must be verified by your organization. Under Verified domains, add the domain, publish the TXT record the page shows (at _faldaro-verification. followed by your domain) with whoever hosts your DNS, and choose Check DNS record. A domain can be verified by one organization only. Members who belong only to your organization and the ones beneath it don't need this.

Keep the TXT record published once the domain is verified. Faldaro looks for it again every day, and a domain whose record is missing on three checks in a row is no longer verified: removing the record un-verifies the domain about three days later, and from then on people who also belong to another organization can't sign in through your provider with an address at that domain. Publish the record again and choose Check DNS record to restore it. A lookup that fails (a timeout, an unreachable DNS server) doesn't count as a missed check.

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 organization and the organizations beneath it, and stays scoped for its whole life — including across every silent renewal.

This matters when a person belongs to more than one organization on Faldaro. Your provider is authoritative for your organization; 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 organizations 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 organization.
  • If they also belong to another organization on Faldaro, their address's domain is verified — and its TXT record is still published (a removed record un-verifies the domain after three daily checks).
  • 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.