Choisir l’authentification

Tale prend en charge les comptes locaux par e-mail et mot de passe, le SSO propre à chaque organisation et les identités transmises par un reverse proxy de confiance. Choisis selon l’endroit où ton équipe gère ses identités et la personne responsable des comptes. L’authentification et le provisionnement sont distincts : le SSO authentifie, tandis que les invitations, le provisionnement à la connexion ou SCIM gèrent l’appartenance. Les agents de code qui modifient des automatisations se connectent à part, au point d’accès MCP, comme décrit plus bas.

Choisir l’intégration adaptée

Le SSO d’entreprise et les en-têtes de confiance se configurent tous deux par organisation. Prépare et teste la correspondance des identités avant de changer le mécanisme de comptes existants.

Fixer d’abord l’URL publique

Définis SITE_URL et l’éventuel chemin de base pris en charge avec l’adresse réellement utilisée. Termine la configuration TLS et des domaines avant d’enregistrer les redirections chez le fournisseur d’identité.

Garde BETTER_AUTH_SECRET identique entre les processus backend de l’instance. Utilise le secret généré par le déploiement ou injecte-le depuis ton gestionnaire. Des valeurs différentes peuvent interrompre la connexion même si le fournisseur d’identité accepte la personne.

Utiliser des comptes locaux

La connexion locale conserve des empreintes de mots de passe dans la base applicative. La première configuration crée le Propriétaire initial ; les membres suivants rejoignent l’organisation sur invitation. Configure l’envoi d’e-mails si ton parcours d’invitation ou de récupération en dépend.

Vérifie avec un compte de test l’invitation, la connexion, la déconnexion et la récupération. Une session Propriétaire qui fonctionne ne prouve pas qu’un nouveau membre peut rejoindre l’organisation.

Tale n’envoie aucun courriel de vérification : une adresse est donc confirmée par qui crée le compte. Le premier Propriétaire issu de la configuration initiale, une personne ajoutée par un administrateur dans Paramètres > Membres et le compte créé par le déploiement valent tous comme confirmation, et le compte est utilisable immédiatement. Les applications connectées lisent cela dans l’attribut email_verified de l’identité délivrée par Tale : un collègue qui vient d’être ajouté peut donc s’y connecter tout de suite. Un compte issu du SSO d’entreprise, de SCIM ou d’en-têtes de confiance conserve en revanche ce qu’indique son annuaire.

Connecter le SSO d’entreprise

Configure l’organisation sous Paramètres > SSO d’entreprise. Microsoft Entra ID et OIDC générique découvrent les endpoints depuis l’émetteur ; OAuth2 utilise des URL explicites d’autorisation, de token et de userinfo. SAML utilise des métadonnées, une URL de réception des assertions et des certificats de signature.

Utilise les URL de callback et de métadonnées affichées. Les callbacks OIDC natifs utilisent /api/sso/callback ; la route de compatibilité /http_api/api/sso/callback reste prise en charge pour les anciennes inscriptions. L’URL enregistrée chez l’IdP doit correspondre à celle utilisée dans le parcours.

Suis SSO d’entreprise et provisionnement pour les protocoles, les claims, les rôles par défaut, les équipes et SCIM. Teste la connexion dans une session distincte avant de fermer ta session d’administration. Une découverte validée ne prouve ni les claims, ni les droits sur les groupes, ni une connexion complète.

Faire confiance à un proxy d’authentification

Une application qui connecte déjà ses utilisateurs peut les faire entrer dans une organisation via son reverse proxy. Un administrateur active la fonction dans Paramètres > SSO d’entreprise, carte En-têtes de confiance : choisis le rôle le plus élevé que le proxy peut attribuer, puis crée une clé et copie-la, car elle ne s’affiche qu’une fois. Fais pointer la connexion du proxy vers /api/trusted-headers/authenticate, avec cette clé dans l’en-tête Remote-Internal-Secret et les en-têtes d’identité Remote-Email, Remote-Name, Remote-Role et Remote-Teams. La référence d’environnement indique les variables TRUSTED_*_HEADER qui permettent de renommer ces en-têtes.

La clé détermine l’organisation. Un membre de cette organisation est connecté ; une adresse que l’instance n’a jamais vue devient un nouveau membre avec le rôle attribué ; un compte existant d’une autre organisation est refusé. Le rôle Propriétaire ne peut jamais être attribué, et un rôle au-dessus du plafond de l’organisation est ramené à ce plafond. À chaque connexion, le siège du membre suit le rôle attribué, si bien que Paramètres > Membres montre ce que le proxy a attribué ; un siège Propriétaire ne change jamais. Désactiver la carte refuse toutes les clés sans en révoquer aucune ; révoquer une clé ne met pas fin aux sessions qu’elle a ouvertes.

Remote-Teams contient des noms d’équipe séparés par des virgules, par exemple Finance,Operations ; une entrée id:name comme t-fin:Finance est aussi acceptée. Les équipes sont rapprochées et créées par nom. Un en-tête absent laisse les équipes inchangées ; un en-tête présent mais vide retire les appartenances accordées par cette synchronisation. Des entrées invalides peuvent donc supprimer ces appartenances. Celles accordées manuellement restent intactes.

Un visiteur qui arrive par le proxy est connecté dès la première requête que l’application fait pour elle-même : si cette requête porte la clé et l’en-tête d’identité mais aucun cookie de session, le backend crée la session sur place et l’application s’ouvre connectée — sans page de connexion, sans redirection. Si l’application atterrit malgré tout sur sa page de connexion (un cookie périmé, par exemple), la page envoie elle-même le navigateur vers l’adresse de passage, et un refus revient sur cette page avec sa raison. Rediriger /log-in du proxy directement vers l’adresse de passage reste possible ; l’adresse répond à un succès par une redirection vers l’application et à un refus par une page avec son code d’état. Le proxy possédant la session, l’application ne propose pas de déconnexion à un membre connecté ainsi ; après une déconnexion pour inactivité, la connexion automatique marque une pause jusqu’à ce que le membre continue depuis l’avis.

Pour afficher Tale dans la page de l’application elle-même plutôt que dans un onglet, un administrateur ajoute l’origine de cette page sous Intégration dans un cadre, sur la même page de paramètres. Les pages de Tale répondent alors avec une règle frame-ancestors qui nomme 'self' et les origines listées au lieu de refuser tout cadre, et l’en-tête X-Frame-Options disparaît. La liste appartient à une organisation, mais l’enveloppe de connexion est un seul document pour toute l’instance : une origine admise par n’importe quelle organisation peut donc la charger. Le navigateur n’envoie le cookie de session dans un cadre que si la page englobante est sur le même site que Tale, par exemple un sous-domaine de l’hôte ou Tale servi sous le domaine de l’hôte ; un cadre d’un autre site affiche la page de connexion.

Laisser les agents de code se connecter

Une personne connecte un agent de code comme Claude Code, Codex ou Cursor au point d’accès MCP en se connectant depuis l’agent : il n’y a pas de clé API à copier dans sa configuration. L’agent envoie le navigateur de la personne vers le serveur de connexion de Tale. Elle s’y connecte comme d’habitude, choisit une organisation et ce que l’agent peut y faire, puis l’agent travaille en son nom, jamais au-delà de son rôle. La connexion est activée tant que tu ne la désactives pas. Les clés API continuent de fonctionner, pour les scripts et pour les outils qui ne savent pas se connecter.

Ce que ton déploiement doit fournir :

• Une adresse publique que les personnes peuvent ouvrir. Le serveur de connexion répond à SITE_URL suivi de /api/auth, et chaque adresse de ADDITIONAL_SITE_URLS est annoncée comme un point d’accès MCP à part.
• Des documents de découverte accessibles. Un agent trouve le serveur de connexion dans des documents sous /.well-known/, à la racine de l’hôte. Le proxy de Tale les transmet. Un proxy à toi doit transmettre /.well-known/oauth-protected-resource* et /.well-known/oauth-authorization-server* au backend sur chaque adresse, y compris quand Tale tourne sous un chemin de base, car ces chemins se trouvent toujours à la racine de l’hôte. TLS et domaines les énumère.
• Un accès HTTPS sortant vers l’hôte de l’agent. Claude Code et Codex se présentent avec un document de métadonnées client publié sur l’hôte de leur éditeur (claude.ai, chatgpt.com), que le backend récupère quand un agent se connecte. Tale refuse les adresses de réseaux privés et les documents situés sur ses propres adresses. Avec TALE_MCP_CLIENT_METADATA_HOSTS, tu limites encore les hôtes acceptés.
• Des limites pour l’auto-enregistrement. Cursor, VS Code et Gemini CLI ne publient pas un tel document et s’enregistrent eux-mêmes. Tale accepte dix enregistrements par heure depuis une même adresse, 500 par jour et 5 000 au total, n’accepte des redirections web que vers les hôtes de TALE_MCP_DCR_WEB_REDIRECT_HOSTS, affiche une telle application comme Non vérifiée et supprime chaque jour les enregistrements que personne n’a utilisés.

Les jetons sont de courte durée. Un jeton d’accès dure cinq minutes, et un agent resté inutilisé pendant trente jours doit être reconnecté. La personne elle-même, ou un propriétaire ou un admin, déconnecte un agent sous Paramètres > API > Agents connectés. Le retrait de la personne de l’organisation, un nouveau mot de passe et un jeton de rafraîchissement utilisé deux fois mettent aussi fin à la connexion ; pour les deux derniers, la personne trouve un avis dans ses notifications.

Pour garder les agents sur des clés API, définis TALE_MCP_CLIENT_METADATA_DOCUMENTS=false et TALE_MCP_DYNAMIC_CLIENT_REGISTRATION=false, puis recrée le backend. Le document oauth-protected-resource du point d’accès répond alors 404, et les jetons d’accès des agents déjà connectés cessent de fonctionner aussitôt. Durcir un déploiement de production liste ce qu’il faut vérifier avant de la laisser activée.

Diagnostiquer les échecs de connexion

Teste les changements de correspondance dans une organisation de staging et garde un accès administratif de secours déjà vérifié. Ces changements peuvent affecter tous les membres dont l’identité dépend de la connexion.