Sign-in & SSO

Fruxon has no passwords. People sign in to the console with Google, Microsoft, or GitHub, with a six-digit code sent to their email, or through their company's identity provider. A workspace controls that with these settings:

"From a console session" means an API token is refused with 403, even one with workspace:write. Domains can also be managed with a token that has workspace:write. The workspace routes on this page live under /v1/tenants/{tenant}, written … below.

How people sign in

The sign-in page offers Continue with Google, Continue with Microsoft, Continue with GitHub, Continue with email, and Continue with SSO. Google One Tap appears on arrival and counts as a Google sign-in. Continue with email sends a six-digit code. Continue with SSO asks for a Work email and sends the person to their company's identity provider.

If someone enters an address on a domain that signs in through SSO, on the sign-in page or the sign-up page, Fruxon sends them to the identity provider instead of emailing a code. That keeps people on SSO by default, but it doesn't stop them choosing Google instead. To close the other ways in, use Sign-in methods.

Domains

Verifying a domain proves your company controls it. It grants nothing on its own. Single sign-on builds on it: Fruxon trusts your identity provider only about addresses on domains you've verified.

1. Open Settings → Domains, enter the domain (for example acme.com), and click Add domain.
2. At your DNS provider, publish the TXT record the page shows. Type is TXT. Name is the domain itself, which many DNS consoles write as @. Value starts with fruxon-domain-verification=.
3. Click Verify. Fruxon looks the record up through a public resolver. If DNS hasn't caught up yet, nothing changes, so try again in a minute.

Leave the record published after the domain is verified. Fruxon re-checks every verified domain daily.

Owners get an email when a domain lapses, 3 days before it's suspended, and when it's suspended. The email links to Settings → Domains with ?workspace= set to the workspace's slug, so the link opens the right workspace even for people who belong to several. The page's heading names the workspace for the same reason.

• Each subdomain is its own claim. Verifying acme.com doesn't cover eng.acme.com.
• Personal and disposable email domains, and Fruxon's own domains, can't be claimed. A workspace can hold up to 50 claims.
• Any number of workspaces can verify the same domain, each with its own TXT record. Add your record next to theirs, and don't replace theirs.
• Remove gives the domain up for this workspace at once, and detaches it from single sign-on.

In the API, the routes are GET …/domains, POST …/domains with a domain field, POST …/domains/{domain}:verify, and DELETE …/domains/{domain}. Here {domain} is the claim's id, not the domain name. Each claim can be checked once every 10 seconds. Checking sooner returns 429.

Single sign-on

Single sign-on lets people sign in through your company's SAML 2.0 identity provider, such as Okta or Microsoft Entra ID. It's part of the Enterprise plan. A workspace has one connection. Nobody signs in through it until you've tested it and turned it on.

To start, open Settings → Single sign-on, fill in Identity provider name (for example Okta), and click Set up single sign-on. The sign-in page shows this name, as in "Sign in with Okta". The page then walks you through four steps.

1. Create a SAML app in your identity provider

Copy the two values the page shows into a new SAML app:

In the app, send each person's email address in an attribute named email. For the NameID, use a persistent identifier, not the email address. Then a person whose address changes keeps the same Fruxon account.

2. Add your identity provider's SAML metadata

Choose Metadata URL or Paste XML, then click Save metadata. For a URL, use the app's Metadata URL in Okta, or the App Federation Metadata Url in Entra ID. Fruxon fetches the URL once, when you save, and doesn't fetch it again later.

Each save creates a new numbered revision. The page lists the revision's identity provider, its sign-in URL, and its signing certificates with their expiry dates. A certificate that expires within 30 days gets a warning. Fruxon refuses metadata that has no signing certificate, an expired certificate, more than two certificates, or a sign-in URL that doesn't use https.

A saved revision reaches the identity platform within a few seconds. Until then it shows Applying…. Then it shows Applied, or Couldn't apply with the reason. To retry a failed revision, save it again.

3. Attach your domains

Pick a domain under Verified domain and click Attach domain. Only people with an address on an attached domain can sign in through the connection, and the address must be on that exact domain. You can attach only domains that are Verified under Domains.

A domain can be attached to only one workspace's single sign-on. If another workspace has already attached it, you get SSO_DOMAIN_ATTACHED_ELSEWHERE. If the domain belongs to your company, contact support.

4. Test and turn on

Click Test sign-in. In the window that opens, sign in as yourself with an address on an attached domain. The test doesn't sign anyone in or change anything. It only records that this revision works. You have 10 minutes to finish it, and only the admin who started a test can complete it.

When the test passes, click Turn on single sign-on. After a few seconds the connection shows On.

Change the configuration later

When your identity provider rotates its certificate, or you change the app, click Replace metadata. The new revision goes only to a test configuration. Everyone keeps signing in with the live revision, and the page tells you which revision that is. Test the new revision, then click Switch to revision N. Only the latest revision can be turned on, and only after it passes a test.

Who gets in

Signing in through SSO signs a person in to Fruxon. The Joining the workspace card decides whether they also join the workspace:

Auto-join stops when the workspace reaches its member limit. If someone has no Fruxon account yet, their first SSO sign-in creates one. They're asked to accept Fruxon's terms the first time the console opens.

Existing members. Turning SSO on changes nothing for current members. When a member first signs in through SSO with the same email address, they get their existing Fruxon account, with their memberships and tokens. Their other sign-in methods keep working unless you restrict them under Sign-in methods.

Starting from your identity provider. To add Fruxon as an app tile in your identity provider, point the tile at https://app.fruxon.com/sso/<workspace-slug>. That page offers Continue with followed by your identity provider's name. If the browser blocks the sign-in window, Fruxon redirects the whole page instead.

Remove access

Removing a person in your identity provider stops them signing in through it. It doesn't end a Fruxon session they already have, remove them from the workspace, or turn off their other sign-in methods. To do that, also remove them under Settings → Team management (see Team & Roles).

Detach stops sign-ins for addresses on that domain at once. Delete connection stops all sign-ins through the connection, detaches its domains, and deletes it. In both cases members stay in the workspace, and sessions that already started stay valid until they end. If you set SSO up again later, you start over with a new app in your identity provider.

If the workspace leaves the Enterprise plan, it can still see its connection, detach domains, and delete the connection. It can't make other changes.

API

PUT …/ssoPolicy replaces the whole policy: jitEnabled, jitRole, and requireSso, which must be false. Each change is recorded in the workspace's audit log.

Sign-in methods

Settings → Sign-in methods controls how members may sign in to reach the workspace. The options are Google, Microsoft, GitHub, Email code, and Single sign-on. Every method is allowed until you save a shorter list. For example, a company that enforces MFA at its identity provider can allow only Single sign-on, so nobody gets in without MFA.

When a member's session was started with a method that isn't allowed, their next request is refused with 403 sign_in_method_not_allowed. The console hides the workspace behind a prompt such as "Sign in with Google or Microsoft to open Acme", with Sign in again and, for members of other workspaces, Switch workspace. A change applies everywhere within 30 seconds.

These rules keep you from locking yourself out:

• At least one method must stay on.
• The method you're signed in with must stay on. To remove it, sign in again with another method first.
• Selecting every method removes the restriction.

API tokens aren't affected. Personal tokens and service accounts keep working under their own scopes and expiry. Changing the list asks you to confirm it's you. In the API, use GET …/signInPolicy and PUT …/signInPolicy. The PUT takes allowedMethods, a list of EMAIL, GOOGLE, MICROSOFT, GITHUB, and SSO.

Confirm it's you

Some changes do lasting damage if someone uses a stolen session to make them. Before these changes, Fruxon asks you to confirm it's you when you signed in more than 15 minutes ago.

The console shows Confirm it's you with the way you signed in: Continue with Google (or Microsoft or GitHub), Email me a code if you signed in with an email code, or Continue with your identity provider's name for an SSO session. After you confirm, the change goes through, and you don't have to start it again. If your sign-in method can't confirm you, the dialog offers Sign in again, and you come back to the same page afterwards.

No other action asks you to confirm. That includes revoking a token and cancelling a scheduled workspace deletion. If you call one of these routes with a console session that's too old, you get 403 with "error": "recent_sign_in_required" and "maxAgeSeconds": 900. The request has no effect, so sign in again and send it again. API tokens are never asked to confirm, because they have no sign-in to check.

Sign out everywhere

POST /v1/users/me:revokeSessions ends every console session you've started, on every device, including the one you call it from. After that, the API refuses those sessions with 401 and "error": "session_revoked", and they can't be refreshed. A session you start afterwards isn't affected.

• It takes effect at once on the server that answers, and everywhere within a minute.
• It isn't tied to one workspace. It ends your sessions in all your workspaces.
• Personal access tokens and CLI keys keep working. Revoke those separately, for example under Settings → Personal tokens.
• You must call it from a console session. An API token gets 403, because a token can't sign its owner out.

The console has no button for this yet. You can only do it through the API.

Error codes

Next steps

• Team & Roles: invite members and manage roles
• Tokens and Service Accounts: programmatic access, which sign-in rules don't affect
• Settings: the rest of the workspace's configuration
• Security: build agents you can put in front of customers