Authentification unique (SSO)

L'authentification unique permet à toute votre équipe de se connecter à CrunchJunkie avec le fournisseur d'identité que votre entreprise utilise déjà (Microsoft Entra ID (Azure AD), Google Workspace, Okta ou tout fournisseur OpenID Connect), sans mot de passe distinct. Les nouveaux collègues sont ajoutés automatiquement à votre espace de travail lors de leur première connexion. Le SSO est disponible avec les forfaits Pro, Agency et Scale, et il est configuré par un propriétaire ou un administrateur de l'espace de travail sous Paramètres → SSO. Sans forfait Pro, Agency ou Scale actif, l'authentification unique est suspendue : votre équipe se connecte avec un mot de passe ou avec Google, et toute personne qui n'a jamais utilisé que le SSO peut définir un mot de passe via Mot de passe oublié. Ce mot de passe est temporaire. Dès que le forfait est de nouveau actif et que le SSO fonctionne, il est supprimé, les sessions ouvertes avec lui prennent fin en une minute environ, et la personne se connecte de nouveau avec le SSO ; nous lui envoyons un e-mail une seule fois à ce moment-là. Un mot de passe que la personne avait auparavant est conservé. Tant que quelqu'un se connecte avec un tel mot de passe temporaire, son adresse e-mail ne peut pas être modifiée. Les clés d'API appartiennent à l'espace de travail et non à un mot de passe : elles ne sont donc pas supprimées. Quand un mot de passe temporaire est supprimé, le journal d'audit de l'administrateur liste les clés d'API que cette personne a créées entre-temps, et un propriétaire ou un administrateur peut les examiner sous Paramètres → API et révoquer celles qui ne sont pas nécessaires. Un propriétaire ou un administrateur peut toujours désactiver le SSO, retirer des domaines ou supprimer la connexion, et le SSO refonctionne dès que le forfait est de nouveau actif. Le SSO est une voie d'accès supplémentaire tant que vous ne l'imposez pas : avec Exiger le SSO activé (voir « Exiger le SSO » plus bas), les membres de vos domaines vérifiés ne peuvent se connecter que par votre fournisseur d'identité. Nous prenons en charge OpenID Connect dès aujourd'hui, ce qui couvre la grande majorité des IdP d'entreprise. Si votre fournisseur ne parle que SAML, contactez-nous : SAML est disponible sur demande avec le forfait Scale.

Dans votre fournisseur d'identité, créez une nouvelle application OIDC (OpenID Connect). Définissez l'URI de redirection avec la valeur affichée sous Paramètres → SSO ; elle ressemble à https://app.crunchjunkie.io/api/auth/sso/callback. Demandez les scopes standard openid, email et profile. Votre IdP vous donnera trois éléments : une URL d'issuer, un client ID et un client secret. Collez-les sous Paramètres → SSO et enregistrez. Le secret est stocké chiffré et ne vous est jamais réaffiché ; pour le changer, il suffit d'en enregistrer un nouveau. Deux configurations courantes. Google Workspace : dans la console Google Cloud, créez un ID client OAuth de type « Application Web », ajoutez-y l'URI de redirection et utilisez https://accounts.google.com comme URL d'issuer. Microsoft Entra ID : enregistrez une application, ajoutez l'URI de redirection comme plateforme « Web » et utilisez https://login.microsoftonline.com/<your tenant id>/v2.0 comme URL d'issuer. Si votre IdP répond « redirect_uri_mismatch », l'adresse qui y est enregistrée diffère de celle affichée sous Paramètres → SSO : copiez-la de nouveau, caractère pour caractère.

Le SSO aiguille une connexion selon le domaine de l'adresse e-mail de l'utilisateur : vous nous indiquez donc les domaines qui vous appartiennent et vous prouvez que vous en êtes propriétaire. Ajoutez un domaine (par ex. acme.com) sous Paramètres → SSO et nous afficherons un enregistrement DNS TXT : ajoutez-le au DNS de ce domaine, puis cliquez sur Vérifier. Un domaine n'aiguille aucune connexion tant qu'il n'est pas vérifié, et chaque domaine ne peut appartenir qu'à un seul espace de travail, personne d'autre ne peut donc revendiquer le vôtre. Un domaine resté non vérifié pendant 30 jours est libéré, afin qu'une revendication inachevée ne puisse pas bloquer le véritable propriétaire du domaine ; pour le vérifier après ce délai, ajoutez-le de nouveau afin d'obtenir un nouvel enregistrement TXT. Ajoutez-le comme nouvel enregistrement TXT sur le domaine lui-même (hôte @, ou laissé vide), à côté des enregistrements TXT existants : SPF et les autres enregistrements de vérification restent en place. Collez la valeur complète, y compris le code après le signe égal : certains panneaux DNS coupent une valeur collée au niveau du « = ». Les modifications DNS peuvent mettre quelques minutes à apparaître ; si Vérifier échoue, patientez et réessayez.

Dès qu'au moins un domaine est vérifié, activez le SSO. À partir de là, un utilisateur ouvre la page de connexion, clique sur « Continuer avec l'authentification unique (SSO) » (ou va directement sur app.crunchjunkie.io/auth/sso), saisit son e-mail professionnel et est envoyé vers votre IdP ; après s'y être authentifié (y compris avec tout second facteur que votre IdP exige), il arrive sur la page Accueil de CrunchJunkie, connecté. La première fois qu'une personne d'un domaine vérifié se connecte, elle est ajoutée automatiquement à votre espace de travail. En coulisses, nous validons le jeton signé du fournisseur d'identité (sa signature, l'issuer, l'audience et un nonce propre à chaque connexion) avant de faire confiance à l'e-mail : seule une réponse authentique de votre IdP peut donc connecter quelqu'un. Et votre IdP ne peut connecter que des adresses des domaines que vous avez vérifiés : une adresse d'un autre domaine est refusée, même si le jeton lui-même est authentique. Vous pouvez désactiver le SSO à tout moment, ce qui cesse immédiatement d'aiguiller les connexions vers votre IdP (les connexions existantes par mot de passe ne sont pas touchées). Activer le SSO ne désactive pas les mots de passe : les personnes qui ont déjà un mot de passe peuvent continuer à l'utiliser, jusqu'à ce que vous activiez Exiger le SSO (section suivante). Tant que le SSO est activé, les membres de votre espace de travail dont l'adresse appartient à l'un de ses domaines vérifiés restent chez votre fournisseur d'identité. Ils ne peuvent changer d'e-mail que pour une autre adresse de ces domaines. Pour déplacer quelqu'un vers toute autre adresse, un propriétaire ou un administrateur ouvre Paramètres → Équipe, clique sur le menu du membre et choisit Modifier l'e-mail de connexion (un administrateur peut le faire pour les membres et les places en lecture seule, le propriétaire pour tout le monde) : un lien de confirmation part vers la nouvelle adresse, le changement s'effectue au clic sur ce lien (dans les 24 heures), l'ancienne adresse reçoit un avis, et les deux étapes sont enregistrées dans notre journal d'audit. Et tant que le SSO fonctionne, Mot de passe oublié n'envoie à ces membres aucun lien de mot de passe, qu'ils aient ou non un mot de passe : ils reçoivent un e-mail qui les renvoie vers l'authentification unique. Le propriétaire de l'espace de travail fait exception : il garde Mot de passe oublié, comme moyen de revenir si votre fournisseur d'identité le bloque (voir Exiger le SSO plus bas). Si le forfait de l'espace de travail expire, les règles des mots de passe temporaires ci-dessus s'appliquent. Tant que le SSO est activé pour un domaine, le formulaire d'inscription ne crée aucun compte avec mot de passe pour ses adresses : l'adresse reçoit à la place un e-mail contenant le lien pour se connecter avec le SSO, et le formulaire répond comme à son habitude, sans révéler si l'adresse a un compte, et aucun lien de confirmation n'est envoyé pour une adresse de ce domaine. Et si quelqu'un a ouvert un compte pour une adresse avant que son titulaire ne l'ait jamais confirmée, le mot de passe et les sessions de ce compte sont supprimés la première fois que la vraie personne se connecte avec le SSO, ou avec un compte Google qui prouve l'adresse (Gmail ou Google Workspace), pour que personne ne puisse créer à l'avance un compte au nom de l'adresse d'un collègue. Ses réglages de double authentification, ses clés d'API et ses autres connexions liées sont supprimés aussi, sauf si la connexion Google qui prouve l'adresse est la seule liée : dans ce cas, c'est la même personne qui les a configurés, elle les conserve et reçoit un e-mail lui indiquant que le mot de passe a été supprimé. Une personne qui avait confirmé son adresse auparavant conserve son mot de passe.

Avec le SSO activé, les mots de passe et « Continuer avec Google » continuent de fonctionner à côté. Pour faire de votre fournisseur d'identité la seule voie d'accès, un propriétaire ou un administrateur active Exiger le SSO sous Paramètres → SSO. À partir de là, les membres dont l'adresse e-mail appartient à l'un de vos domaines vérifiés ne peuvent se connecter qu'avec le SSO, de sorte que les règles de double authentification de votre IdP et son processus de départ s'appliquent à chaque connexion. Leur mot de passe et leur connexion Google sont refusés avec « Votre entreprise exige la connexion avec le SSO », et une session qu'ils n'ont pas ouverte avec le SSO prend fin en une minute environ, à leur prochaine page ou requête. Les membres dont l'adresse appartient à un autre domaine, comme un consultant externe sur gmail.com, ne sont pas concernés, pas plus que les personnes extérieures à votre espace de travail. Une personne invitée dans votre espace de travail avec une adresse de vos domaines le rejoint en se connectant avec le SSO. L'option ne peut être activée que lorsque le SSO est activé avec un domaine vérifié, que l'espace de travail a un forfait Pro, Agency ou Scale actif et que quelqu'un s'est connecté au moins une fois par votre connexion, ce qui prouve que la configuration fonctionne. Avant l'activation, une confirmation liste chaque membre concerné et chaque membre épargné, avec les effectifs, les invitations en attente vers vos domaines et les clés d'API actives que ces membres ont créées. L'activation et la désactivation sont consignées dans notre journal d'audit. Désactiver le SSO, ou retirer son dernier domaine vérifié, désactive aussi Exiger le SSO ; le réactiver demande une nouvelle confirmation. Tant que l'espace de travail n'a pas de forfait actif, le SSO est suspendu et Exiger le SSO l'est avec lui, de sorte que personne n'est bloqué. Si votre fournisseur d'identité est en panne, le propriétaire de l'espace de travail peut toujours se connecter avec son mot de passe et son authentification à deux facteurs : un code d'application d'authentification ou l'un de ses codes de récupération. Google reste refusé. C'est pourquoi Exiger le SSO ne peut être activé que lorsque le propriétaire a les deux, pourquoi le propriétaire ne peut pas désactiver la double authentification tant qu'elle est requise, et pourquoi la propriété ne peut passer qu'à une personne qui a les deux (ou dont l'adresse n'appartient pas à vos domaines). Chaque connexion de ce type est consignée, et le propriétaire reçoit un e-mail à chaque fois. Tant que votre SSO est activé, le propriétaire peut toujours utiliser Mot de passe oublié, avec ou sans Exiger le SSO. Personne ne peut changer à la place du propriétaire son e-mail de connexion, le rôle de propriétaire ne peut donc pas être pris de cette façon ; si le propriétaire perd à la fois son mot de passe et son application d'authentification, contactez-nous. Les clés d'API continuent de fonctionner : elles appartiennent à l'espace de travail, pas à la session d'une personne, et les intégrations cesseraient de fonctionner si elles s'arrêtaient. Examinez celles qui figurent dans la confirmation sous Paramètres → API. Les assistants IA (MCP) agissent comme la personne : pour ces membres, le connecteur ne fonctionne donc que si leur dernière connexion a été faite après une connexion avec le SSO ; un assistant connecté depuis une connexion par mot de passe ou Google, avant ou après l'activation de Exiger le SSO, cesse de fonctionner jusqu'à ce que la personne le reconnecte après s'être connectée avec le SSO. Exiger le SSO décide de la manière dont les gens se connectent ; il ne retire personne. Une session ouverte avec le SSO continue de fonctionner tant qu'elle est utilisée et prend fin après 7 jours d'inactivité : pour couper l'accès de quelqu'un immédiatement, retirez-le sous Paramètres → Équipe, ce qui met fin à son accès à l'espace de travail et révoque les clés d'API qu'il a créées. Changer de fournisseur d'identité alors que Exiger le SSO est activé (nouvel issuer, nouveau client ID ou nouveau secret) le laisse activé : les nouveaux réglages doivent fonctionner tout de suite, et s'ils ne fonctionnent pas, le propriétaire se connecte avec son mot de passe et son authentification à deux facteurs pour les corriger ou désactiver Exiger le SSO. Le changement est consigné dans notre journal d'audit. Après un tel changement, la réactivation de Exiger le SSO attend que quelqu'un se soit connecté avec le SSO via les nouveaux réglages. Supprimer la connexion SSO désactive Exiger le SSO, et cela est consigné aussi.

Une tentative échouée renvoie à la page de connexion avec un court message. Voici ce que chacun signifie : « L'authentification unique n'est pas disponible pour ce domaine e-mail » : le domaine n'est pas vérifié, le SSO n'y est pas activé, ou l'espace de travail n'a pas de forfait Pro, Agency ou Scale actif. Le message est le même dans chaque cas, de sorte que la page de connexion ne révèle à personne le forfait d'un espace de travail ; en attendant, connectez-vous avec votre mot de passe ou Google (pas encore de mot de passe ? utilisez Mot de passe oublié pour en définir un). « Nous n'avons pas pu joindre le fournisseur d'identité de votre entreprise » : l'URL d'issuer sous Paramètres → SSO est erronée ou l'IdP est en panne. « Nous n'avons pas pu vérifier la réponse de votre fournisseur d'identité » ou « Votre fournisseur d'identité n'a pas renvoyé de jeton de connexion » : le client ID ou le client secret ne correspond pas à l'application de l'IdP. « Cette tentative de connexion a expiré ou a été ouverte dans un autre navigateur » : la tentative a duré plus de dix minutes, ou les cookies sont bloqués ; recommencez. « Votre fournisseur d'identité n'a pas confirmé votre adresse e-mail » : l'IdP ne se porte pas garant de cette boîte aux lettres, nous ne la connecterons donc pas. « … dont le domaine n'est pas vérifié pour l'authentification unique de votre espace de travail » : votre IdP a renvoyé une adresse d'un domaine que vous n'avez pas vérifié (un domaine alias ou un sous-domaine, par exemple) ; vérifiez aussi ce domaine, ou faites envoyer par l'IdP l'adresse de votre domaine vérifié. « L'authentification unique (SSO) de votre entreprise est de nouveau active » : le mot de passe que vous avez utilisé a été défini pendant que le SSO était indisponible, et maintenant que le SSO fonctionne de nouveau, il a été supprimé : cliquez sur « Continuer avec l'authentification unique (SSO) ». « Votre entreprise exige la connexion avec le SSO » : Exiger le SSO est activé dans votre espace de travail, votre mot de passe et Google ne vous connectent donc pas : cliquez sur « Continuer avec l'authentification unique (SSO) ». Une erreur affichée par l'IdP lui-même (par exemple « redirect_uri_mismatch ») signifie qu'il faut corriger l'application qui y est enregistrée, pas CrunchJunkie.