Single Sign-On (SSO)

Single Sign-On (SSO) lets members of your workspace sign in with your company identity provider — Okta, Entra ID, Google Workspace, OneLogin, JumpCloud, or any IdP that speaks OIDC or SAML 2.0.

SSO is a Teams plan feature. Configuration lives in Settings → Workspace → Security. Only a workspace Owner can add, change, or remove a provider; Admins see the same panel read-only.

Set up your provider

Pick your identity provider for a step-by-step walkthrough. Every path ends at the same place: a verified domain and a live provider.

What Fuser reads from your IdP

This is the contract between your IdP and Fuser. Getting it wrong is the single most common cause of a broken connection, so configure it deliberately rather than trusting your IdP's defaults.

SAML attributes

Attribute names are matched exactly and without a namespace. An attribute sent as http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress does not match email.

displayName is read only when both givenName and surname are absent.

The NameID identifies the account

Sending email does not make the NameID unimportant. The NameID is the identifier Fuser stores for the account, and on every sign-in after the first it is what resolves the member — the address in the assertion is not re-checked at that point.

Two properties follow, and your IdP has to guarantee both:

• Unique per person. Two members must never present the same NameID. A collision signs the second member in as the first, and because Fuser accounts are not scoped to one workspace, that reaches everywhere the first member has access.
• Stable for a person. A member whose NameID changes is treated as a new identity for your provider. They are re-attached by email address on the next sign-in, so a stable, non-reassignable identifier — a directory GUID rather than a mail address or a login name — is the safer choice.

Never use the SAML transient NameID format, which issues a fresh value on every sign-in.

OIDC claims

Fuser requests the openid, email, profile, and offline_access scopes and reads the standard claims.

What Fuser ignores

• email_verified / equivalent SAML attributes. Fuser does not treat your IdP's verification claim as authority. A member's email is marked verified because the provider's domain passed DNS verification and their address is inside it — a stronger signal than a claim.
• Roles, groups, and entitlements. Everyone who signs in through SSO joins with the Member role. Promote people in Members.

The domain boundary

When Fuser creates a member's account, the address in the assertion must be inside the provider's verified domain or one of its subdomains. An identity outside that domain is rejected rather than silently creating an account — this is what stops a provider from claiming identities it does not own.

Before you start

You need admin access to your identity provider, and the ability to add a DNS TXT record for your domain. Both ends have to exist before sign-in works:

1. An application in your IdP that Fuser can authenticate against.
2. A provider in Fuser holding that application's credentials.
3. A DNS TXT record proving you own the email domain.

The IdP application and the Fuser provider reference each other, so you will go back and forth once: create the app in your IdP with placeholder URLs, register it in Fuser, then paste Fuser's real endpoint URLs back into the IdP.

Registering the provider in Fuser

Every provider guide passes through this form. Open Settings → Workspace → Security → Single Sign-On, pick OIDC or SAML, and fill it in:

Click Add provider.

Provider settings are final

A registered provider cannot be edited. There is no way to correct an issuer, a sign-on URL, a certificate, or a client secret in place — the only path is Remove and register again.

That is not a like-for-like swap. Each registration mints a fresh internal identifier, and Fuser derives three things from it:

• the ACS URL,
• the Entity ID / Audience URI,
• the DNS TXT record name.

So re-registering gives you new endpoint URLs and a new record. Whatever you already pasted into your IdP is stale, the TXT record you already published no longer matches, and the domain has to be verified again.

Client secrets are additionally write-only: Fuser never displays a saved secret again, even to an owner.

The new provider card then lists the URLs your IdP needs. Copy each one into the matching field in your IdP application.

OIDC

SAML

While the domain is unverified the card keeps these fields open, since wiring the IdP up is the only thing left to do. Once it verifies they collapse — reopen them any time with Show details on the card.

Verifying the domain with DNS

Until the domain is verified, the provider is inert — nobody can sign in through it. The card shows a TXT record to add at your DNS provider:

• Queried hostname — the full hostname Fuser looks up, e.g. _fuser-sso-acme-com-a1b2c3.acme.com. Many DNS consoles append your domain automatically; if yours does, enter only the leading label.
• Record value — copy it exactly.

Fuser rechecks the record on its own every 20 seconds for about five minutes, and you can hit Check now at any time. DNS propagation usually takes a few minutes but can take longer.

The record expires after a week. If it lapses before verification completes, use Get a new record to issue a fresh one.

Once the record is found, the card flips to Verified — SSO active and members on that domain can sign in through your IdP.

Requiring SSO

By default, a verified provider is an option — members can still sign in with email or Google. The Require SSO toggle on the panel makes it mandatory: every member whose email is on a verified SSO domain must go through your IdP.

• The toggle only becomes available once a domain is verified. Enforcing before then would lock everyone out.
• Workspace owners always keep email sign-in. If your IdP goes down or is misconfigured, an owner can still get in and turn enforcement off.
• Enforcement matches subdomains too. If you verify acme.com, a member at eng.acme.com is covered — unless a more specific provider for eng.acme.com exists, in which case that one wins.

What members see

The sign-in screen always offers a Use single sign-on (SSO) link under the email field. A member can take it directly, or enter their email as usual — Fuser then looks up the domain and adapts:

• No SSO for that domain — the normal email code and Continue with Google options. Taking the SSO link says no provider is set up for that domain.
• SSO available, not required — the code screen also shows a Continue with SSO button.
• SSO required — the email code and Google options disappear and the only path is Continue with SSO, with a note that their team requires it.

Clicking through redirects to your IdP and back. A member signing in through a verified provider for the first time joins the workspace automatically with the Member role. Roles are never taken from IdP attributes — promote people in Members as usual.

Removing a provider

Remove on the provider card deletes it. Members who signed in through it keep their accounts and workspace membership, and fall back to email sign-in — unless Require SSO is still on and another verified provider covers their domain.

If your workspace drops off the Teams plan, existing SSO configuration stays visible and enforcement keeps running. The panel keeps the Disable and Remove controls available so you are never stuck with members locked behind a provider you can no longer manage.

Troubleshooting

What's Next?