Sign in with your identity provider

You can connect a site to your organization's own identity provider. Your people then sign in to the web client with the account they already have, your provider's own rules apply (its passwords, its MFA, its conditional access), and disabling somebody at the provider ends their ability to start new sign ins here.

Everything on this page lives on Site settings, Identity provider.

What it covers, and what it does not

The browser, and only the browser

Federated sign in works where a browser works: the web client. SFTP, FTPS and FTPES have no way to carry a browser sign in, so a federated user reaches those with an app password they create after signing in to the web client, or with an SSH key you register for them.

The protocol supported is OpenID Connect, which Microsoft Entra ID, Google Workspace, Okta, Auth0, Keycloak and most modern providers all speak. SAML is not supported.

Before you start: register the application at your provider

Your provider needs to know about your site before it will sign anyone in to it. In your provider's admin console, create an application (the exact word varies: app registration, OAuth client, OIDC web app) and register the redirect addresses the Identity provider tab shows you.

There is one redirect address per address your site is served on: the platform address, plus each verified custom domain. Register each one exactly as shown, with no trailing slash. If you add a custom domain later, come back and register its address too, or sign ins started on that domain will fail at the provider.

The registration gives you a client id and a client secret; those are what you enter here.

Setting it up

Field	What to enter
Provider	Microsoft Entra ID, Google Workspace, Okta, or Other OpenID Connect. The choice prefills sensible shapes; it does not change what is supported
Issuer	The provider's issuer address, exactly as its discovery document states it
Entra tenant id	Entra ID only: your directory (tenant) id. With it set, the issuer can be left empty and is derived for you
Client id	From the application you registered
Client secret	From the application you registered. Write only: once saved, the page only ever says whether one is set
Sign in button label	What the button on the web client sign in page says. Leave empty for "Sign in with your organization"; naming your provider ("Sign in with Okta") helps your people recognize it

Provider specifics:

• Microsoft Entra ID: create an app registration, single tenant. Note that client secrets in Entra expire; put the expiry in your calendar, because sign ins stop working the day it lapses.
• Google Workspace: create an OAuth client of type web application. The issuer is https://accounts.google.com.
• Okta: create an OIDC web app. The issuer is your Okta org address.

Use Test connection at any time: it asks the provider for its discovery document and reports what it found, without saving anything.

Saving runs the same live check. If the provider cannot be reached at the issuer you typed, nothing is saved and the page tells you so. That way a typo fails here, in front of you, and never as an unexplained failed sign in for one of your people.

Who may sign in

The provider proves who a person is. These rules decide which of its accounts your site accepts:

• Allowed email domains. Only accounts whose verified email is on one of these domains are accepted. Leave empty to accept any address the provider verifies. Set it whenever your provider could vouch for addresses outside your organization.
• Allowed groups. If set, the account must carry at least one of these groups in the token's groups claim. Your provider must be configured to include groups in its tokens for this to work.
• Email claim and Groups claim are advanced settings for providers that use nonstandard claim names. The defaults (email, groups) are right for the major providers.

An account the provider vouches for is matched to a user on your site by its verified email, once, on its first successful sign in. From then on the link is by the provider's stable subject, so a later email change at the provider does not move the account.

Two refusals are deliberate and permanent:

• An address that belongs to a password or key user on your site is refused, never silently converted. Switch the user's sign in method yourself if that is what you want.
• An address already linked to a different provider account is refused. The link is one to one.

Creating federated users

Two ways.

Create them yourself. On the Users page, create a user and set Sign in method to Organization sign in. An email is required; it must match the address your provider reports for that person. The user shows Pending first sign in until they sign in once, which completes the link. See Users.

Let the first sign in create them. Turn on Create unknown users automatically. A person your provider accepts, who passes the domain and group rules above, and who has no account here yet, gets one created on the spot from the template you configure (which protocols, whether they may share). Their username derives from their email: jane.doe@example.com becomes jane.doe@yoursite, with a number appended if that name is taken.

An account is not storage

A created account has an identity and nothing else. Until a Connector administrator grants them a folder, their sign in is refused with a message that says exactly that. The first granted storage becomes their home automatically; see Create your first user for how homes work.

Automatic creation consumes a seat per created user, exactly like a user you create yourself. When the site has no spare seat, the sign in is refused and nothing is created.

Turning it off

Switch Enable organization sign in off. The button disappears from the web client sign in page and federated sign ins stop. Existing sessions run to their normal end; app passwords your users created keep working, because they are separate credentials, revocable one by one on each user.

Clearing the client secret also stops sign ins, since the provider round trip cannot complete without it.

What lands in Activity

Enabling, changing or disabling the provider is recorded in Activity with the issuer and client id, never the secret. Every automatic account creation is recorded as its own entry naming the created user.