Single sign-on (SSO)

With single sign-on, members sign in to Maketools with their company account (Microsoft Entra ID, Okta, Google Workspace or any OIDC or SAML 2.0 provider). SSO is part of the Pro and Enterprise plans.

Owners and Admins set it up in Organisation → Single sign-on (SSO). Two-step verification is required for these settings, and saving or removing the connection asks you to confirm your identity again. Every change is recorded in the audit log.

How it works

1. You declare Maketools in your identity provider, then enter the provider settings in Maketools.
2. You verify the email domains of your organisation (for example acme.com) with a DNS record.
3. A member clicks Sign in with SSO and enters their work email. Maketools finds the organisation that verified this domain and sends the member to your identity provider.
4. On the first sign-in, the account is created and added to the organisation with the role of new members you chose (Member by default, never Owner). An existing account with the same email is linked, not duplicated.

SSO only applies to verified domains. Your identity provider can only sign in addresses of these domains: an address from another domain is refused.

Step 1: declare Maketools in your identity provider

The SSO page shows the values to copy:

Microsoft Entra ID

• OIDC (recommended): in App registrations, create an application with the Web redirect URI shown by Maketools. Create a client secret. In Token configuration, add the optional claims email and xms_edov: without xms_edov, the email address is not considered verified and sign-in is refused. The issuer URL is https://login.microsoftonline.com/<tenant ID>/v2.0.
• SAML: in Enterprise applications, create a non-gallery application, choose SAML, enter the entity ID and reply URL shown by Maketools, then copy the App Federation Metadata Url into Maketools.

Okta

• OIDC: create an OIDC - Web Application app integration, with the sign-in redirect URI shown by Maketools and the Client secret authentication. The issuer URL is your Okta domain (https://<your-org>.okta.com) or your authorization server (https://<your-org>.okta.com/oauth2/default).
• SAML: create a SAML 2.0 app integration. Single sign-on URL = ACS URL, Audience URI = entity ID, Name ID format = EmailAddress. Copy the Metadata URL into Maketools.

Google Workspace

• OIDC: in Google Cloud, create an OAuth client ID of type Web application with the redirect URI shown by Maketools. The issuer URL is https://accounts.google.com. Restrict the OAuth consent screen to your organisation (Internal).
• SAML: in the Admin console, Apps → Web and mobile apps → Add custom SAML app. ACS URL and entity ID come from Maketools, Name ID format = EMAIL. Download the IdP metadata and paste the XML into Maketools.

Step 2: enter the provider settings

Choose the protocol:

• OIDC: issuer URL, client ID and client secret. The secret is stored encrypted and never shown again; leave the field blank to keep it.
• SAML: metadata URL or pasted metadata XML. Maketools reads the entity ID, the sign-on URL and the signing certificates of the provider.

With OIDC, Maketools servers call your provider at every sign-in (code exchange, signing keys). They have no fixed IP address: a provider hosted on your premises that only accepts allowlisted addresses (firewall, internal ADFS or Keycloak) will reject these calls. In that case, choose SAML: the assertion travels through the user's browser and Maketools never calls your provider at sign-in (paste the metadata XML rather than its URL). Cloud providers (Entra ID, Okta, Google Workspace) are not affected.

Then choose the role of new members and a break-glass account (see below), and save. Test the connection checks that the provider answers and that its signing keys are usable, without signing anyone in.

Step 3: verify your domains

Add each email domain of your organisation. Maketools shows a TXT record such as maketools-verification=…: add it to the DNS zone of the domain, then click Verify. DNS changes can take a few minutes, sometimes a few hours. A verified domain belongs to a single organisation.

Two-step verification with SSO

A Maketools session opened by SSO counts as two-step verified only when your identity provider says so in its signed answer:

• OIDC: the amr claim contains mfa;
• SAML: a strong authentication context (for example http://schemas.microsoft.com/claims/multipleauthn or https://refeds.org/profile/mfa), or the Entra ID authnmethodsreferences claim containing multipleauthn.

Otherwise, the Maketools rules apply: a member who has two-step verification in Maketools enters their code after SSO, and a member your organization requires it from cannot act until two-step verification is done. Turn on MFA in your identity provider and make it send this information: your members then sign in only once.

Require SSO

When SSO is required, password sign-in, email codes, sign-up and Google or Microsoft sign-in are refused for the addresses of your verified domains: these members are sent to SSO. Before you can require SSO, the connection must be enabled and tested, at least one domain must be verified, and a break-glass account must be chosen.

Sessions that are already open stay valid until they expire. Changing this setting asks you to confirm your identity and is recorded in the audit log.

Break-glass account

If your identity provider is down, nobody could sign in. The break-glass account is an Owner of the organisation who keeps password sign-in even when SSO is required. Protect it with a long password and two-step verification, keep its use exceptional, and review the audit log after each use. If this person stops being an Owner, the exception no longer applies.

Plan changes

SSO requires the Pro plan or above. If the organisation moves to a lower plan, SSO sign-in stops and SSO is no longer required, so that members can sign in with their other methods.

Security

• OIDC: authorization code flow with PKCE, state and nonce; the ID token signature is checked against the provider keys, as well as its issuer, audience, expiry and email_verified.
• SAML: sign-in always starts from Maketools. Signed assertions are required, and Maketools checks the audience, destination, recipient, validity window, issuer and the request it answers. Each assertion is accepted only once. Unsolicited answers (IdP-initiated) are refused.
• The sign-in is bound to the browser that started it, and the session is opened with a one-time code valid for 60 seconds.
• Audit log: sso.configured, sso.domain.verified, sso.login.succeeded, sso.login.failed, sso.enforced.