Single sign-on (SSO)

With single sign-on, your users sign in with the account they already use for work – at Microsoft Entra ID (Microsoft 365), Google Workspace or your own OpenID Connect provider such as Okta, Keycloak or Auth0. They then no longer need a separate password for allverto.

#What you need

• The Manage users permission (only an owner can turn SSO required on or off).
• For Microsoft the tenant ID of your directory, for Google the Workspace domain, for your own provider the issuer URL, client ID and client secret.
• The email domains your people sign in with (e.g. company.com).

#Setting up

Open gear → Security and scroll to the Single sign-on card.

1. Turn on single sign-on.
2. Under Provider, choose Microsoft Entra ID, Google Workspace or Custom OpenID Connect provider. If a provider is greyed out, allverto has not set it up yet – tapping it shows the reason.
3. Enter the provider details (see below).
4. Under Allowed email domains, add your domains. Only addresses with these domains sign in via single sign-on. Public providers such as gmail.com or web.de are not possible.
5. Save and then Test sign-in.

#Microsoft Entra ID

allverto has its own multi-tenant app at Microsoft. You only enter which directory applies:

1. In the Microsoft Entra admin center, copy the Tenant ID under Overview.
2. Paste it in allverto under Tenant ID (directory ID).
3. On the first sign-in, Microsoft asks for consent for the app “allverto”. If people may not consent themselves, an administrator grants consent once for the whole organisation (Enterprise applications → allverto → Permissions → Grant admin consent).

allverto uses the account's sign-in name (UPN) as the email address, e.g. erika@company.com. It must match the address the person was invited with in allverto. allverto rejects accounts from other directories – including guest accounts.

#Google Workspace

1. Under Google Workspace domain, enter the primary domain of your Workspace, e.g. company.com.
2. Done – allverto uses its own app at Google. The Google sign-in only shows accounts of this organisation; private Gmail accounts are rejected.

#Custom OpenID Connect provider (Okta, Keycloak, Auth0 …)

1. At the provider, create a new application of type Web (authorization code with PKCE).
2. Enter the address from the card as the Redirect URI (Copy button next to Redirect URI).
3. Allow the scopes openid, email and profile.
4. In allverto, enter the Issuer URL (https address, e.g. https://company.okta.com), Client ID and Client secret, and optionally a Button label (e.g. “Okta”).
5. Save. Each domain then shows a TXT record: create it at your DNS provider and click Check. Only verified domains can sign in.

The client secret is stored encrypted at allverto and is never shown again. Leaving the field empty keeps the stored secret.

#Test sign-in

Test sign-in opens the sign-in at the provider in a popup. allverto then shows what was received (e.g. email, name, directory) and whether the sign-in would work – you are not signed in. Reasons for a rejection are listed in the result, e.g. “This email domain is not allowed for this company's single sign-on”.

Save before testing; changed settings need a new test before SSO required can apply.

#Signing in

• On the sign-in page, enter the email address first. If the domain belongs to your company, Sign in with Microsoft appears (or Google, or your button label).
• Under Direct sign-in link you find an address like allverto.cloud/login/sso/your-company that leads straight to the provider – handy as a bookmark or on your intranet.
• allverto matches the account by email address (upper and lower case don't matter). The person must be a member of your company – or be created automatically (see below). People who work in several companies switch via the company menu as usual.
• The session lasts as long as with a password sign-in; automatic sign-out after inactivity applies as well.

#SSO required

With SSO required, all users of the company sign in via single sign-on only. When you turn it on, running password sessions of the other users end. Anyone who also works in a company without SSO required can keep signing in there with a password; switching to your company then requires single sign-on.

Requirements:

Emergency access: owners can still sign in with a password despite SSO required – but only with two-factor sign-in set up. That way you can get into allverto even if the provider is down. The sign-in page shows Sign in as owner with password (emergency access) for this.

#Create users automatically

By default, only people invited in allverto can sign in. With Create users automatically, everyone with an allowed domain gets access with the chosen Default role on their first sign-in. The Owner role cannot be selected. Deactivated users stay deactivated.

Keep in mind: every new active user counts towards your subscription.

#Log

Every sign-in via single sign-on is recorded in the System log. Rejected sign-ins are also recorded in the Firewall – each with a reason, e.g. domain not allowed, account from another directory or no access in the company. allverto never stores tokens or secrets.

#Frequently asked questions

#The sign-in page shows no “Sign in with …” button.

Check that single sign-on is turned on, that the email's domain is listed under Allowed email domains and – for a custom provider – verified via DNS. The direct link works regardless.

#“There is no access in this company for this email address.”

The person has not been invited. Invite them under Users or turn on Create users automatically. For Microsoft: does the sign-in name (UPN) match the email address in allverto?

#What happens if we change plans?

Without the Flotte plan, single sign-on is off, including SSO required. Everyone then signs in with a password again (“Forgot password?” sets a new one if needed). The settings remain saved.