Authentification unique pour une installation on-premise

Cette page s'adresse aux opérateurs d'une installation MonoChat on-premise. Elle explique comment permettre à vos équipes de se connecter avec le fournisseur d'identité (IdP) de votre entreprise via OpenID Connect (OIDC), par exemple Microsoft Entra ID, Okta, Keycloak, AD FS ou Google Workspace.

L'authentification unique se configure pour toute l'installation dans les paramètres du serveur, pas par organisation. Un compte MonoChat peut appartenir à plusieurs organisations, et l'on se connecte avant d'en choisir une. Se connecter donne un compte, pas un accès : une personne ne voit une organisation qu'après que celle-ci l'a invitée et lui a attribué un rôle.

Fonctionnement de la connexion

Quand une personne clique sur le bouton SSO de la page de connexion, MonoChat ouvre la page de connexion de votre IdP dans une fenêtre pop-up. Une fois la personne connectée, l'IdP renvoie le navigateur vers MonoChat avec un code à usage unique. Le serveur MonoChat échange ce code contre un jeton d'identité (ID token) et le vérifie avant de connecter la personne :

• Les points de terminaison et les clés de signature de l'IdP sont lus dans son document de découverte, <issuer>/.well-known/openid-configuration, à chaque connexion.
• La connexion utilise le flux du code d'autorisation avec PKCE (S256), un state et un nonce. Une demande de connexion est valable 10 minutes et ne peut servir qu'une fois.
• Le jeton d'identité doit être signé avec l'une des clés de l'IdP et porter votre émetteur (iss), votre identifiant client (aud), le nonce de la demande et une date d'expiration (exp) non dépassée.
• Le jeton d'identité doit contenir l'adresse e-mail de la personne (email). La connexion est refusée quand l'IdP indique que l'adresse n'est pas vérifiée (email_verified: false).

1. Enregistrez MonoChat auprès de votre fournisseur d'identité

Créez une application (un client) pour MonoChat dans votre IdP avec ces valeurs :

Paramètre dans l'IdP	Valeur
Type d'application	Application web avec un secret client (client confidentiel)
URI de redirection de connexion	https://<your MonoChat domain>/api/oauth/oidc/redirect
Type d'octroi	Code d'autorisation
Portées (scopes)	openid email profile
Authentification du client au point de terminaison du jeton	Secret client envoyé par l'authentification HTTP Basic (client_secret_basic)

Vérifiez que le jeton d'identité contient la claim email. Notez l'identifiant client, le secret client et l'émetteur. L'émetteur est la valeur issuer du document de découverte de l'IdP. Formes courantes :

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 plus récent)	https://<your AD FS host>/adfs
Google Workspace	https://accounts.google.com

Ouvrez <issuer>/.well-known/openid-configuration dans un navigateur et copiez sa valeur issuer à l'identique, y compris un / final s'il y en a un. MonoChat refuse toute connexion quand les deux diffèrent.

2. Ajoutez les paramètres

Ajoutez les blocs oidc aux paramètres du serveur et redémarrez MonoChat. Le bloc public va sous public.oauth, le bloc secret sous oauth :

{
  "oauth": {
    "oidc": {
      "clientSecret": "<client secret>",
      "autoCreateAccounts": true,
      "allowedEmailDomains": ["company.com"]
    }
  },
  "public": {
    "oauth": {
      "oidc": {
        "issuer": "https://login.microsoftonline.com/<tenant id>/v2.0",
        "clientId": "<client id>",
        "redirectPath": "/api/oauth/oidc/redirect",
        "scope": "openid email profile",
        "buttonLabel": "Sign in with Company SSO"
      }
    }
  }
}

Paramètre	Effet
public.oauth.oidc.issuer	L'émetteur de l'étape 1
public.oauth.oidc.clientId	L'identifiant client de l'étape 1
public.oauth.oidc.redirectPath	Le chemin de l'URI de redirection de l'étape 1
public.oauth.oidc.scope	Les portées demandées par MonoChat
public.oauth.oidc.buttonLabel	Le texte du bouton de connexion. Vide, il affiche « Se connecter avec SSO » dans la langue de la personne
oauth.oidc.clientSecret	Le secret client. Il reste sur le serveur
oauth.oidc.autoCreateAccounts	true crée le compte MonoChat à la première connexion SSO d'une personne, même quand l'inscription se fait uniquement sur invitation (public.disableSignup)
oauth.oidc.allowedEmailDomains	Seules les personnes dont l'adresse e-mail appartient à l'un de ces domaines peuvent se connecter par SSO. Omettez-le pour autoriser tous les domaines

Le bouton SSO apparaît alors sur la page de connexion.

Qui peut se connecter

• Les nouvelles personnes. Avec autoCreateAccounts: true, la première connexion SSO d'une personne crée son compte. Sans ce paramètre, le compte n'est créé que si public.disableSignup est désactivé ou si la personne se connecte depuis une invitation.
• Les personnes qui ont déjà un compte avec la même adresse e-mail. Avec oauth.autoMerge: true, la première connexion SSO relie le SSO au compte existant, mais seulement quand le jeton d'identité indique que l'adresse est vérifiée (email_verified: true). Sinon, et toujours sans autoMerge, MonoChat demande à la personne de se connecter une fois avec son mot de passe, puis relie le SSO au compte ; accepter une invitation à une organisation le relie aussi. Microsoft Entra ID et AD FS n'envoient pas email_verified : avec eux, laissez la connexion par mot de passe autorisée jusqu'à ce que tout le monde ait relié le SSO, ou invitez de nouveau les personnes.
• Les domaines autorisés. Avec allowedEmailDomains, une adresse d'un autre domaine est refusée. Pour Google Workspace (émetteur https://accounts.google.com), MonoChat vérifie la claim hd, le domaine Workspace du compte, au lieu de l'adresse e-mail, car un compte Google personnel peut utiliser une adresse de n'importe quel domaine.

Faire du SSO la seule méthode de connexion

1. Définissez 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 réseau social.
2. Les utilisateurs root super (ayant le rôle root super dans l'organisation racine) peuvent toujours se connecter avec leur mot de passe à /auth/signin?fallback=1, pour que l'installation ne soit jamais bloquée si l'IdP est indisponible.
3. Pour empêcher les nouveaux comptes SSO d'ouvrir leurs propres organisations, définissez public.disableTenantCreation sur true. Seules les personnes ayant le rôle adéquat dans une organisation peuvent alors créer des organisations sous celle-ci.

Réseau

• Gardez /api/oauth/oidc/authorize et votre redirectPath accessibles aux personnes qui se connectent. Les deux s'ouvrent dans leur navigateur.
• Le serveur MonoChat doit pouvoir joindre en HTTPS le document de découverte, le point de terminaison du jeton et le jeu de clés (jwks_uri) de votre IdP.

Limites

• L'application mobile MonoChat ne propose pas encore le SSO. Si vous faites du SSO la seule méthode de connexion, les agents ne peuvent pas se connecter à l'application mobile.
• Se déconnecter de MonoChat ne déconnecte pas la personne de l'IdP, et se déconnecter de l'IdP ne la déconnecte pas encore de MonoChat.

Vérifiez votre configuration

1. Ouvrez la page de connexion et cliquez sur le bouton SSO. Connectez-vous dans votre IdP ; la fenêtre pop-up se ferme et vous êtes connecté à MonoChat.
2. Connectez-vous avec une personne qui n'a pas encore de compte MonoChat et vérifiez que le compte est créé (ou refusé, si vous n'avez pas activé autoCreateAccounts).
3. Si vous avez défini allowedEmailDomains, essayez avec une personne d'un autre domaine et vérifiez que la connexion est refusée.
4. Si vous avez défini public.auth.methods, vérifiez qu'une connexion par mot de passe est refusée et qu'un utilisateur root super peut toujours se connecter à /auth/signin?fallback=1.