Authentification unique (SSO)

Avec l'authentification unique, vos membres se connectent à Maketools avec leur compte d'entreprise (Microsoft Entra ID, Okta, Google Workspace ou tout fournisseur OIDC ou SAML 2.0). Le SSO fait partie des offres Pro et Enterprise.

Les Propriétaires et les Admins le configurent dans Organisation → Authentification unique (SSO). La vérification en deux étapes est exigée pour ces réglages, et enregistrer ou retirer la connexion demande de confirmer votre identité. Chaque changement est inscrit au journal d'audit.

Fonctionnement

1. Vous déclarez Maketools chez votre fournisseur d'identité, puis vous saisissez les réglages du fournisseur dans Maketools.
2. Vous vérifiez les domaines d'email de votre organisation (par exemple acme.fr) par un enregistrement DNS.
3. Un membre clique sur Se connecter avec le SSO et saisit son email professionnel. Maketools retrouve l'organisation qui a vérifié ce domaine et l'envoie vers votre fournisseur.
4. À la première connexion, le compte est créé et ajouté à l'organisation avec le rôle des nouveaux membres choisi (Membre par défaut, jamais Propriétaire). Un compte existant avec le même email est relié, pas dupliqué.

Le SSO ne s'applique qu'aux domaines vérifiés. Votre fournisseur ne peut connecter que des adresses de ces domaines : une adresse d'un autre domaine est refusée.

Étape 1 : déclarer Maketools chez votre fournisseur

La page SSO affiche les valeurs à recopier :

Microsoft Entra ID

• OIDC (recommandé) : dans Inscriptions d'applications, créez une application avec l'URI de redirection Web affichée par Maketools. Créez un secret client. Dans Configuration du jeton, ajoutez les revendications facultatives email et xms_edov : sans xms_edov, l'adresse n'est pas tenue pour vérifiée et la connexion est refusée. L'URL de l'émetteur est https://login.microsoftonline.com/<ID du locataire>/v2.0.
• SAML : dans Applications d'entreprise, créez une application hors galerie, choisissez SAML, saisissez l'entity ID et l'URL de réponse affichés par Maketools, puis recopiez l'URL des métadonnées de fédération d'application dans Maketools.

Okta

• OIDC : créez une intégration OIDC - Web Application, avec l'URI de redirection affichée par Maketools et l'authentification par Client secret. L'URL de l'émetteur est votre domaine Okta (https://<votre-org>.okta.com) ou votre serveur d'autorisation (https://<votre-org>.okta.com/oauth2/default).
• SAML : créez une intégration SAML 2.0. Single sign-on URL = URL ACS, Audience URI = entity ID, Name ID format = EmailAddress. Recopiez la Metadata URL dans Maketools.

Google Workspace

• OIDC : dans Google Cloud, créez un ID client OAuth de type Application Web avec l'URI de redirection affichée par Maketools. L'URL de l'émetteur est https://accounts.google.com. Limitez l'écran de consentement à votre organisation (Interne).
• SAML : dans la console d'administration, Applications → Applications Web et mobiles → Ajouter une application SAML personnalisée. URL ACS et entity ID viennent de Maketools, Format de l'ID de nom = EMAIL. Téléchargez les métadonnées du fournisseur et collez le XML dans Maketools.

Étape 2 : saisir les réglages du fournisseur

Choisissez le protocole :

• OIDC : URL de l'émetteur, client ID et secret client. Le secret est conservé chiffré et jamais réaffiché ; laissez le champ vide pour le garder.
• SAML : URL des métadonnées ou XML collé. Maketools y lit l'entity ID, l'URL de connexion et les certificats de signature du fournisseur.

En OIDC, les serveurs de Maketools appellent votre fournisseur à chaque connexion (échange du code, clés de signature). Ils n'ont pas d'adresse IP fixe : un fournisseur hébergé chez vous qui n'accepte que des adresses autorisées (pare-feu, ADFS ou Keycloak interne) refusera ces appels. Dans ce cas, choisissez SAML : l'assertion passe par le navigateur de l'utilisateur et Maketools n'appelle jamais votre fournisseur à la connexion (donnez alors le XML des métadonnées plutôt que leur URL). Les fournisseurs en ligne (Entra ID, Okta, Google Workspace) ne sont pas concernés.

Choisissez ensuite le rôle des nouveaux membres et un compte de secours (voir plus bas), puis enregistrez. Tester la connexion vérifie que le fournisseur répond et que ses clés de signature sont utilisables, sans connecter personne.

Étape 3 : vérifier vos domaines

Ajoutez chaque domaine d'email de votre organisation. Maketools affiche un enregistrement TXT du type maketools-verification=… : ajoutez-le à la zone DNS du domaine, puis cliquez sur Vérifier. Un changement DNS peut prendre quelques minutes, parfois quelques heures. Un domaine vérifié n'appartient qu'à une seule organisation.

Vérification en deux étapes et SSO

Une session Maketools ouverte par le SSO ne compte comme vérifiée en deux étapes que si votre fournisseur l'affirme dans sa réponse signée :

• OIDC : la revendication amr contient mfa ;
• SAML : un contexte d'authentification fort (par exemple http://schemas.microsoft.com/claims/multipleauthn ou https://refeds.org/profile/mfa), ou la revendication Entra ID authnmethodsreferences contenant multipleauthn.

Sinon, les règles de Maketools s'appliquent : un membre qui a activé la vérification en deux étapes dans Maketools saisit son code après le SSO, et un membre que votre organisation y oblige ne peut pas agir tant qu'elle n'est pas faite. Activez la MFA chez votre fournisseur et faites-lui transmettre cette information : vos membres ne se connectent alors qu'une fois.

Imposer le SSO

Quand le SSO est imposé, la connexion par mot de passe, les codes par email, l'inscription et la connexion Google ou Microsoft sont refusés pour les adresses de vos domaines vérifiés : ces membres sont renvoyés vers le SSO. Pour l'imposer, la connexion doit être activée et testée, au moins un domaine doit être vérifié, et un compte de secours doit être choisi.

Les sessions déjà ouvertes restent valables jusqu'à leur expiration. Changer ce réglage demande de confirmer votre identité et est inscrit au journal d'audit.

Compte de secours (break-glass)

Si votre fournisseur d'identité tombe, plus personne ne pourrait se connecter. Le compte de secours est un Propriétaire de l'organisation qui garde la connexion par mot de passe même quand le SSO est imposé. Protégez-le par un mot de passe long et la vérification en deux étapes, gardez son usage exceptionnel et relisez le journal d'audit après chaque usage. Si cette personne n'est plus Propriétaire, l'exception ne s'applique plus.

Changement d'offre

Le SSO demande l'offre Pro ou supérieure. Si l'organisation passe à une offre inférieure, la connexion SSO s'arrête et le SSO n'est plus imposé, pour que les membres puissent se connecter par leurs autres méthodes.

Sécurité

• OIDC : flux « authorization code » avec PKCE, state et nonce ; la signature du jeton d'identité est vérifiée avec les clés du fournisseur, ainsi que son émetteur, son audience, son expiration et email_verified.
• SAML : la connexion part toujours de Maketools. Les assertions signées sont obligatoires, et Maketools vérifie l'audience, la destination, le destinataire, la fenêtre de validité, l'émetteur et la requête à laquelle elles répondent. Chaque assertion n'est acceptée qu'une fois. Les réponses non sollicitées (IdP-initiated) sont refusées.
• La connexion est liée au navigateur qui l'a commencée, et la session s'ouvre par un code à usage unique valable 60 secondes.
• Journal d'audit : sso.configured, sso.domain.verified, sso.login.succeeded, sso.login.failed, sso.enforced.