Configuration SSO

Connectez Okta, Microsoft Entra ID ou Google Workspace pour que votre équipe se connecte via votre fournisseur d'identité.

Configuration SSO

Ce guide s'adresse à l'administrateur IT qui connecte un fournisseur d'identité (IdP) d'entreprise à InterMIND. Après la configuration, les membres se connectent depuis la page de connexion habituelle : Se connecter avec SSO → e-mail professionnel → votre IdP → retour dans InterMIND.

Disponible sur : plans Business et Enterprise Configuré par : le propriétaire de l'équipe ou un administrateur Protocole : OpenID Connect (OIDC). La connexion SAML 2.0 est en cours de développement — la configuration SAML est enregistrée mais ne permet pas encore de se connecter.

Prérequis

  1. Un domaine vérifié — vérifiez au préalable votre domaine d'e-mail via un enregistrement DNS TXT (voir Gestion des domaines). La connexion SSO n'accepte que les comptes dont le domaine d'e-mail a été vérifié par votre équipe ; c'est la frontière du tenant.
  2. Un IdP prenant en charge OIDC avec discovery — il doit exposer /.well-known/openid-configuration sous l'Issuer URL. Okta, Microsoft Entra ID et Google le font tous.

Ce qu'il faut enregistrer dans votre IdP

Créez une application web OIDC dans votre IdP avec :

ParamètreValeur
Redirect URI (callback)https://intermind.com/api/auth/sso/callback — également affichée dans la carte SSO après que vous avez sélectionné OIDC
Type d'autorisationAuthorization Code (PKCE S256 est utilisé automatiquement)
Scopesopenid email profile

Le jeton d'identité émis par votre IdP doit inclure le champ email de l'utilisateur, et le domaine de cet e-mail doit faire partie de vos domaines vérifiés — sinon la connexion est refusée.

Remplissez ensuite la carte SSO sur la page Intégrations :

ChampCe qu'il faut coller
Nom d'affichageTout libellé que vos membres reconnaîtront
Issuer URLL'issuer de votre IdP — l'URL qui expose /.well-known/openid-configuration
Authorization URLLe authorization_endpoint de ce document de discovery
Client ID / Client SecretIssus de l'application que vous avez enregistrée

Le client secret est chiffré au repos et n'est jamais renvoyé au navigateur après l'enregistrement.

Okta

  1. Console d'administration → Applications → Create App Integration → méthode de connexion OIDC, type d'application Web Application
  2. Sign-in redirect URI : https://intermind.com/api/auth/sso/callback
  3. Assignez les utilisateurs ou groupes qui doivent avoir accès
  4. Copiez le Client ID et le Client Secret
  5. Dans InterMIND : Issuer URL = l'URL de votre organisation Okta (par ex. https://acme.okta.com, ou l'issuer de votre serveur d'autorisation tel que https://acme.okta.com/oauth2/default si vous en utilisez un) ; Authorization URL = le authorization_endpoint issu de <issuer>/.well-known/openid-configuration

Microsoft Entra ID (Azure AD)

  1. Centre d'administration Entra → App registrations → New registration
  2. Plateforme Web, redirect URI https://intermind.com/api/auth/sso/callback
  3. Certificates & secrets → New client secret — copiez immédiatement la Value du secret
  4. Client ID = l'Application (client) ID affiché sur la page Overview
  5. Assurez-vous que le jeton d'identité contient l'e-mail de l'utilisateur : Token configuration → Add optional claim → ID → email
  6. Dans InterMIND : Issuer URL = https://login.microsoftonline.com/<tenant-id>/v2.0 ; Authorization URL = https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize

Google Workspace

Aucun enregistrement d'application n'est nécessaire. Dans la carte SSO, choisissez le type de fournisseur Google Workspace et enregistrez — les membres de vos domaines vérifiés se connectent avec leur compte Google et rejoignent automatiquement votre équipe. (Google peut aussi être connecté comme un fournisseur OIDC générique avec l'issuer https://accounts.google.com si vous préférez fournir explicitement des identifiants client.)

Tester la connexion

  1. Ouvrez la page de connexion dans une fenêtre privée/incognito
  2. Cliquez sur Sign in with SSO et saisissez un e-mail professionnel sur votre domaine vérifié
  3. Vous êtes redirigé vers votre IdP ; après authentification, vous revenez dans InterMIND, connecté
  4. La connexion est consignée dans le journal d'audit de l'équipe (exportable depuis la page Users) en tant que auth.login avec la méthode sso

Dépannage

SymptômeCause
« SSO is not configured » après la saisie de l'e-mailAucune configuration SSO active ne correspond à ce domaine d'e-mail — vérifiez que le domaine est vérifié et que la carte SSO est enregistrée
SSO login is not available: planLe plan de l'équipe n'inclut plus le SSO
SSO login is not available: domain-not-verifiedLe domaine est encore en attente de vérification DNS
SSO login is not available: config-incompleteClient ID ou Client Secret manquant — réenregistrez la carte SSO
SSO login is not available: type-unsupportedLa configuration enregistrée est SAML — la connexion SAML n'est pas encore disponible
SSO IdP discovery failedL'Issuer URL est incorrecte ou n'expose pas /.well-known/openid-configuration
« login session expired, start again »Plus de 5 minutes se sont écoulées entre le démarrage de la connexion et le callback de l'IdP
Connexion refusée après le retour depuis l'IdPL'IdP a renvoyé un e-mail hors de vos domaines vérifiés, ou aucune revendication email (Entra : ajoutez la revendication d'e-mail optionnelle)

Propriétés de sécurité

Pour les questionnaires de sécurité : le flux SSO repose sur Authorization Code avec PKCE (S256), state et nonce ; la signature du jeton d'identité est validée contre le JWKS de l'IdP, ainsi que l'issuer et l'audience ; l'IdP fait autorité uniquement pour les domaines vérifiés via DNS — une assertion pour tout autre e-mail ne produit jamais de session ; le client secret OIDC est chiffré au repos ; chaque connexion SSO est consignée dans le journal d'audit de l'équipe. Les contrôles de plan, de domaine et de configuration sont appliqués côté serveur à la fois au démarrage de la connexion et au callback.