Single sign-on
Let people sign in with the Microsoft, Google or GitHub account they already have, or through your own identity provider (OpenID Connect).
On this page
Setting up a provider
- Set the Site URL under Control panel › General first.
- Open Control panel › Single sign-on and choose the provider. The page shows a redirect address to copy.
- Register ThirtyFile with the provider (see below) and paste that address there.
- Copy the ID and secret the provider gives you into ThirtyFile, switch the provider on and save.
Microsoft Entra ID
Microsoft Entra admin center › App registrations › New registration. Select the "Web" platform and enter the redirect address, then add a client secret under "Certificates & secrets". The application ID and tenant ID are on the "Overview" page.
Google Cloud Console › APIs & Services › Credentials › Create credentials › OAuth client ID. Choose "Web application" and add the redirect address under "Authorized redirect URIs".
GitHub
GitHub › Settings › Developer settings › OAuth Apps › New OAuth App. Enter the redirect address as the callback URL, then generate a client secret.
OpenID Connect (Keycloak, Authentik, Authelia, Zitadel…)
Create a confidential client (a web application) in your identity provider with the redirect address, and note its client ID and secret. In ThirtyFile, enter the Issuer URL (for Keycloak, https://auth.example.com/realms/<realm>) and a name for the sign-in button, such as "Company login". When you save, ThirtyFile reads the provider's settings from <issuer>/.well-known/openid-configuration; the issuer must be an https address, and the document must name the same issuer.
The provider must include the person's email address and mark it as verified (the email scope and claim, and email_verified), otherwise people can only link the account themselves. Allowed domains, domain rules, linking and automatic accounts work as with the other providers.
Who may sign in
Each provider has its own rule for people who sign in for the first time:
| Rule | What happens |
|---|---|
| Linked accounts only | Only people who linked the account themselves, from their account menu |
| Match existing users by email | People whose email is the username of an account without a password or two-factor sign-in, such as one single sign-on created for that same email. An account that has either, like one an administrator created, isn't matched, because signing in through the provider would skip them: its owner signs in with the password once and links the account |
| Create accounts automatically | Anyone from an allowed email domain gets a new account |
With automatic accounts, list the allowed email domains, for example example.com, so that only your own people get in.
Different settings for different domains
Rules by email domain give new accounts their own permissions, space size and groups. For example, partners from partner.example can get a smaller space and no permission to share.
A rule can also decide whether new accounts get a personal space, My files, and on which storage location. Left as As in the system settings, they follow Control panel › General. When the location's folder isn't available, the person still gets in, and their "My files" is created there once it is back.
Linking an account yourself
Anyone can link or unlink an account of each provider set up here (Microsoft, Google, GitHub or OpenID Connect) under Account menu › Sign-in methods. A linked account signs in without the password, so linking asks for the current password first, and with two-factor sign-in a code; accounts without a password link within 10 minutes of signing in. The person gets a notification, in the app and by email, for every account linked to theirs, including one matched by email.
When a list of allowed domains is set, only an account whose email address the provider verified, in one of those domains, can be linked. Only verified addresses are kept with a linked account.
Microsoft tenants with guests
With a tenant ID set, the members of your tenant are matched by email. Guests from other organisations sign in through your tenant too, but their email address comes from their own organisation, which can enter any address. So a guest's email doesn't match or create an account: guests sign in with a password and link their Microsoft account themselves.
To match guests by email as well, add the optional claim xms_edov to the ID token: in the app registration, Token configuration › Add optional claim › ID › xms_edov. Microsoft then says when the domain of a guest's email address belongs to their organisation, and only those guests are matched.