Authentification unique (SSO) pour votre plateforme de messagerie client : guide OpenID Connect pour les équipes support

L’authentification unique (SSO) d’une plateforme de messagerie client, c’est vos agents qui se connectent avec leur compte professionnel chez votre fournisseur d’identité, comme Microsoft Entra ID, Okta, Keycloak, AD FS ou Google Workspace, au lieu d’un mot de passe distinct. Le standard qui la rend possible s’appelle OpenID Connect (OIDC). Sur une installation MonoChat on-premise, vous la configurez une seule fois pour toute l’installation, vous la limitez aux domaines e-mail de votre entreprise et vous pouvez en faire le seul moyen de connexion.

Les équipes support ont une raison particulière de s’y intéresser. Le compte d’un agent ouvre toutes les conversations WhatsApp, Instagram et Messenger qu’il peut voir : noms, numéros de téléphone, détails de commande, parfois des questions de santé ou de paiement. Ce compte doit suivre les mêmes règles que les autres comptes de l’entreprise, et cesser de fonctionner le jour où la personne part.

Pourquoi la connexion compte pour une équipe support

Les identifiants volés ou détournés restent la porte d’entrée la plus courante dans une entreprise. Le rapport Data Breach Investigations 2025 de Verizon, qui a analysé 12 195 violations confirmées, a constaté que l’abus d’identifiants (22 %) et l’exploitation de vulnérabilités (20 %) étaient les principaux vecteurs d’attaque initiaux.

Une plateforme de messagerie qui gère ses propres mots de passe ajoute à chaque agent un jeu d’identifiants de plus : un mot de passe de plus à réutiliser, un compte de plus à oublier quand quelqu’un part, une connexion de plus que vos règles d’authentification multifacteur (MFA) et d’accès conditionnel ne couvrent pas. Avec le SSO, la plateforme ne voit jamais le mot de passe. Votre fournisseur d’identité le vérifie, applique votre MFA et vos politiques d’accès, puis indique à la plateforme qui s’est connecté.

Comment fonctionne la connexion OpenID Connect

OpenID Connect est une couche d’identité au-dessus d’OAuth 2.0. Le flux utilisé par MonoChat est le flux de code d’autorisation (authorization code flow) :

1. L’agent clique sur le bouton SSO de la page de connexion. MonoChat ouvre la page de connexion de votre fournisseur d’identité dans une fenêtre pop-up.
2. L’agent s’y connecte, avec votre MFA et vos politiques.
3. Le fournisseur d’identité renvoie le navigateur vers MonoChat avec un code à usage unique.
4. Le serveur MonoChat échange ce code contre un jeton d’identité (ID token), de serveur à serveur. Les jetons ne transitent jamais par le navigateur.
5. MonoChat vérifie le jeton d’identité et connecte l’agent.

Le jeton d’identité est, selon les termes de la spécification OpenID Connect, « a security token that contains Claims about the Authentication of an End-User ». MonoChat ne l’accepte que dans ces conditions :

• il est signé avec l’une des clés de votre fournisseur d’identité, lue à chaque connexion dans son document de découverte (<issuer>/.well-known/openid-configuration) ;
• son émetteur (iss) est votre émetteur, son audience (aud) est l’identifiant client de MonoChat et son expiration (exp) n’est pas dépassée ;
• il contient le nonce envoyé par MonoChat avec la requête, ce qui lie le jeton à cette connexion et empêche tout rejeu ;
• il contient l’adresse e-mail de la personne, et le fournisseur ne signale pas cette adresse comme non vérifiée.

La requête utilise aussi PKCE (S256) et une valeur state ; une demande de connexion est valable 10 minutes et ne peut servir qu’une fois.

Cinq décisions à prendre avant d’activer le SSO

Décision	Options	Notre recommandation pour une équipe support
Qui peut se connecter	Tous les domaines, ou uniquement les domaines e-mail de votre entreprise	Limitez-le à vos domaines
Que se passe-t-il à la première connexion	Créer le compte, ou n’accepter que les personnes invitées	Créez les comptes si votre fournisseur d’identité contrôle déjà qui travaille chez vous
Comptes existants	Lier le SSO à la première connexion quand l’e-mail est vérifié, ou après une connexion par mot de passe	Cela dépend de l’envoi ou non de email_verified par votre fournisseur
Autres méthodes de connexion	Garder mots de passe et comptes sociaux, ou SSO uniquement	SSO uniquement, une fois que tout le monde a lié son SSO
Qui peut ouvrir de nouveaux espaces de travail	Toute personne ayant un compte, ou seulement les personnes ayant le bon rôle	Désactivez la création libre d’espaces de travail dans une installation d’entreprise

Notez ces choix avant de modifier le moindre réglage. Ce sont les questions que posera votre équipe sécurité, et les réponses déterminent les paramètres dont vous avez besoin.

Configurer le SSO sur une installation MonoChat on-premise

Le SSO se configure pour toute l’installation dans les paramètres serveur, pas par espace de travail. La référence complète est la page sur l’authentification unique du centre d’aide ; voici la version courte.

1. Enregistrer MonoChat chez votre fournisseur d’identité

Créez une application web avec un secret client, et donnez-lui :

• l’URI de redirection https://<your MonoChat domain>/api/oauth/oidc/redirect ;
• le type d’autorisation « authorization code » ;
• les scopes openid email profile ;
• l’authentification du client avec le secret envoyé en HTTP Basic (client_secret_basic).

Vérifiez que le jeton d’identité inclut la claim email, et notez l’identifiant client, le secret client et l’émetteur (issuer).

2. Copier l’émetteur à l’identique

L’émetteur est la valeur issuer du document de découverte de votre fournisseur. Formes habituelles :

Fournisseur d’identité	Émetteur (issuer)
Microsoft Entra ID	https://login.microsoftonline.com/<tenant id>/v2.0
Okta	https://<your Okta domain>/oauth2/default ou https://<your Okta domain>
Keycloak	https://<your Keycloak host>/realms/<realm>
AD FS 2016 ou version ultérieure	https://<your AD FS host>/adfs
Google Workspace	https://accounts.google.com

Ouvrez <issuer>/.well-known/openid-configuration dans un navigateur et copiez la valeur caractère par caractère, y compris une éventuelle barre oblique finale. MonoChat refuse toutes les connexions quand les deux valeurs diffèrent : c’est la cause la plus fréquente d’échec du premier test.

3. Ajouter les paramètres et redémarrer

La partie publique (émetteur, identifiant client, chemin de redirection, scopes et texte du bouton) va sous public.oauth.oidc ; le secret client va sous oauth.oidc et reste sur le serveur. Deux options de ce bloc traduisent vos décisions du tableau ci-dessus :

• autoCreateAccounts: true crée le compte MonoChat à la première connexion SSO d’une personne, même quand l’inscription est sur invitation uniquement ;
• allowedEmailDomains: ["yourcompany.com"] refuse toute adresse d’un autre domaine. Pour Google Workspace, MonoChat vérifie le domaine Workspace du compte (la claim hd) plutôt que l’adresse e-mail, car un compte Google personnel peut utiliser une adresse sur n’importe quel domaine.

Le bouton affiche « Se connecter avec SSO » dans la langue de chaque personne, ou le libellé que vous avez défini, par exemple « Se connecter avec Northwind SSO ».

4. Faire du SSO la seule méthode, sans risque

Quand tout le monde a lié son SSO, réglez les méthodes de connexion autorisées (public.auth.methods) sur ["oidc"]. La page de connexion n’affiche alors que le bouton SSO, et le serveur refuse la connexion par mot de passe et par compte social. Les super-utilisateurs root peuvent toujours se connecter avec leur mot de passe à l’adresse /auth/signin?fallback=1 : un fournisseur d’identité en panne ne bloque donc jamais l’installation. Pour empêcher les nouveaux comptes SSO d’ouvrir leurs propres espaces de travail, réglez public.disableTenantCreation sur true.

5. Tester quatre connexions

1. Une personne qui a un compte : la pop-up se ferme et elle est connectée.
2. Une personne sans compte : le compte est créé, ou la connexion est refusée si vous n’avez pas activé la création de comptes.
3. Une personne d’un autre domaine : refusée, si vous avez limité les domaines.
4. Une connexion par mot de passe avec le SSO seul activé : refusée, alors que la connexion de secours root fonctionne toujours.

Agents existants : comment les comptes sont liés

La plupart des équipes activent le SSO alors que leurs agents ont déjà des comptes MonoChat. MonoChat lie le SSO à un compte existant ayant la même adresse e-mail de l’une des deux façons suivantes :

• Automatiquement, à la première connexion SSO, quand l’installation autorise la fusion et que le jeton d’identité indique que l’adresse est vérifiée (email_verified: true).
• Après une connexion par mot de passe, dans tous les autres cas : MonoChat demande à la personne de se connecter une fois avec son mot de passe et lie alors le SSO. Accepter l’invitation à un espace de travail le lie aussi.

Microsoft Entra ID et AD FS n’envoient pas email_verified. Avec eux, laissez la connexion par mot de passe autorisée tant que tout le monde n’a pas lié son SSO, ou invitez de nouveau les personnes, avant de passer au SSO uniquement.

Le SSO donne l’identité, les rôles donnent l’accès

Se connecter donne un compte à une personne, pas l’accès à vos conversations. Un compte MonoChat peut appartenir à plusieurs espaces de travail, et les personnes se connectent avant d’en choisir un. Une personne ne voit un espace de travail que lorsqu’il l’a invitée et lui a attribué un rôle, et c’est le rôle qui détermine les canaux, les conversations et les paramètres auxquels elle accède. Consultez les rôles et autorisations de la boîte de réception d’équipe pour savoir comment les définir.

C’est cette séparation que demandera un auditeur :

• Arrivée : le fournisseur d’identité crée la personne ; un administrateur de l’espace de travail l’invite et choisit son rôle.
• Mobilité : changez le rôle ou le groupe de travail dans MonoChat ; la connexion ne change pas.
• Départ : désactivez la personne chez le fournisseur d’identité, et retirez-la de l’espace de travail dans MonoChat.

Limites à prévoir

• L’application mobile. L’application MonoChat pour Android et iOS ne propose pas encore le SSO. Si le SSO est la seule méthode de connexion, les agents ne peuvent pas se connecter sur leur téléphone : gardez une autre méthode pour les utilisateurs mobiles, ou prévoyez des services sur ordinateur uniquement.
• Déconnexion. Se déconnecter de MonoChat ne déconnecte pas la personne du fournisseur d’identité, et se déconnecter du fournisseur ne la déconnecte pas encore de MonoChat. Désactiver une personne qui part chez le fournisseur d’identité empêche toute nouvelle connexion ; retirez-la aussi de l’espace de travail.
• Réseau. Les navigateurs des utilisateurs doivent pouvoir joindre /api/oauth/oidc/authorize et le chemin de redirection, et le serveur MonoChat doit pouvoir joindre en HTTPS le document de découverte, le point de terminaison des jetons et le jeu de clés de votre fournisseur. Si vous restreignez aussi l’installation par adresse IP, gardez ces chemins en tête.

Où se place le SSO dans MonoChat

Le SSO se configure dans les paramètres serveur d’une installation entière : aujourd’hui, il relève donc de MonoChat on-premise, l’option Enterprise pour les équipes qui font tourner la plateforme sur leurs propres serveurs, avec leur propre LLM et leur propre base vectorielle. La page Enterprise présente l’option on-premise, et la page sécurité couvre l’accès par rôles, l’isolation des espaces de travail et les certifications. Pour le volet données d’un déploiement d’IA, consultez la checklist de confidentialité des chatbots IA.

Pour essayer d’abord le produit lui-même, le plan Basic gratuit sur app.monochat.ai vous donne un agent et un canal.

Sources

• OpenID Connect Core 1.0, OpenID Foundation, consulté le 4 novembre 2026
• Annonce du Verizon 2025 Data Breach Investigations Report, consulté le 4 novembre 2026
• Centre d’aide MonoChat : Single Sign-On for an On-Premise Installation, consulté le 4 novembre 2026
• Changelog MonoChat 3.8.43, 2 novembre 2026