Sign-in and single sign-on

All sign-in settings are in the app, under Admin → Authentication (Owner and Admin staff). Nothing here needs a restart.

Sign-in methods at a glance

Method	Where it's set up	Notes
Username & password	Admin → Authentication → Sign-in methods	Passwords are stored as slow, salted hashes (argon2id).
Single sign-on (OIDC)	Admin → Authentication → OIDC providers	Google, Microsoft Entra ID, Apple, GitLab, Okta, Auth0, Keycloak, Authentik, or any OpenID Connect provider.
Passkeys	Each person, in their security settings	Always in addition to a password or single sign-on.
Two-factor authentication	Each person, in their security settings	Authenticator-app codes for password accounts.

At least one sign-in method always stays enabled.

Single sign-on (OIDC)

To add an identity provider:

1. Open Admin → Authentication and choose Add provider.
2. Pick a preset (it fills in the issuer and the usual claims) or Custom OIDC. The dialog shows a hint where to create the client in that provider's console.
3. Copy the Redirect URI shown in the dialog and register it as an allowed redirect (callback) in your identity provider. It looks like https://flow.example.com/api/auth/oidc/<name>/callback.
4. Enter the Display name, the Issuer, the Client ID and the Client secret from the provider. Replace placeholders such as {tenant-id} or {realm} in the issuer.
5. Choose Test connection — it checks that the issuer's discovery document can be read.
6. Review the Claim mapping (username, email and groups claims) and the options below, then Save.

The sign-in page then shows "Continue with …" for each enabled provider. Client secrets are stored encrypted.

Options

• Create users on first sign-in: unknown people get an account automatically. Off: people the instance doesn't know yet can't sign in with this provider.
• Add new users to: a workspace (and role) that new accounts join, or none.
• Admin group and Support group: members of these provider groups get the Admin or Support staff role on sign-in; the role is removed again when they leave the group. Owners are never changed. See Staff roles.
• Group mappings: people in a provider group are added to a workspace with a role on every sign-in, and removed when they no longer are in the group. A mapping to No workspace access removes its members from every workspace and board and wins over other mappings.

The groups claim must be present in the ID token or user info. Some providers need a "groups" mapper or scope for that (Keycloak: a groups mapper; Okta: the groups scope).

Email addresses from the provider

When the provider sends email_verified: true, the address counts as confirmed. When it doesn't (Microsoft Entra ID, for example, sends no such claim) and Require email verification is on, a new account gets a confirmation email first; after confirming, the person signs in with the provider again, and groups and the default workspace are applied then. With the setting off, addresses from the provider count as confirmed. See Email verification.

If your provider doesn't send the claim but your organization manages the addresses in its directory (typical for Microsoft Entra ID), turn on Trust this provider's email addresses in the provider's settings (Admin → Authentication, select the provider). It is off by default. With it on, addresses from that provider count as confirmed even without email_verified, so new accounts skip the confirmation email. Changing it is recorded in the audit log. Only turn it on for a provider whose users can't set an arbitrary address themselves.

Two-factor authentication with single sign-on

People who sign in with an identity provider don't get sol2flow's own two-factor step: their provider is responsible for it. Enforce MFA there.

Passkeys

People add passkeys themselves (Settings → Security → Passkeys) and can then sign in without a password, also from the browser's autofill. A passkey with biometrics or a device PIN counts as two factors, so no code is asked for.

Passkeys are tied to the host name in APP_URL. If you change the domain, existing passkeys stop working and have to be added again — people can still sign in with their password or single sign-on. See Account and security.

Two-factor authentication

Anyone with a password can turn on two-factor authentication with an authenticator app, and gets ten one-time recovery codes. If someone loses both their authenticator and their codes, staff can reset it with a reason that is recorded in the audit log: Users and sign-up.

Sessions

• Remember me off (default): the session ends when the browser closes, and after 12 hours at most.
• Remember me on: 30 days, extended while the person keeps using sol2flow.
• People see their signed-in devices and can sign them out in Settings → Security → Sessions. Disabling an account signs it out everywhere at once.

Self sign-up

Under Admin → Authentication → Self sign-up you decide whether people may create their own accounts:

• Allowed email domains: only addresses at these domains may sign up (empty = any).
• New accounts join: a workspace (and role) every new account is added to, or none.
• Require admin approval: new accounts wait until a staff member approves them in Admin → Users.
• Require email verification (on by default): new accounts confirm their address with an emailed link before they can sign in, and a changed address only applies once it's confirmed. It needs working email; if your instance can't send email, turn it off.

Details: Users and sign-up.

Rate limits

Sign-in, sign-up, password reset, two-factor codes and passkeys are rate-limited per IP address and per account. Make sure your proxy passes client addresses correctly (Client IP addresses), or everyone shares one limit.