ÉQUIPE & ACCÈS

SSO et authentification à deux facteurs

Connectez-vous via votre fournisseur d’identité, et exigez un second facteur sur chaque compte.

Deux façons indépendantes de renforcer une connexion. Le SSO confie la question de votre identité à un fournisseur que vous exploitez déjà. Le second facteur conserve le mot de passe local mais exige une preuve supplémentaire. Les deux se combinent : une installation peut exiger les deux.

Authentification unique

Trois formes de fournisseur sont proposées, configurées par un administrateur plateforme dans Admin → Configuration :

Fournisseur	Nécessite
Google	Un identifiant client et un secret. Les points d’accès sont connus : aucun aller-retour de découverte.
GitHub	Un identifiant client et un secret sur une application OAuth. Scopes `read:user user:email`.
OIDC	Une URL d’émetteur, un identifiant client et un secret — Keycloak, Authentik, Okta, Entra, tout ce qui publie un document de découverte. Un libellé nomme le bouton.

Un fournisseur n’est actif que si son identifiant et son secret sont renseignés — un fournisseur à moitié configuré n’affiche pas de bouton plutôt qu’un bouton qui échoue. Les secrets sont stockés chiffrés et ne sont jamais renvoyés par l’API de configuration.

GitHub n’est pas OIDC. Il n’émet pas d’id_token, et l’adresse principale est souvent privée sur le profil — elle n’apparaît, avec son indicateur de vérification, que derrière un second point d’accès. C’est l’unique raison de son traitement particulier ; Google et votre propre émetteur reposent sur le même protocole.

Comment une identité externe devient un compte local

Le sujet immuable du fournisseur — le sub de Google, l’id numérique de GitHub — identifie la personne, jamais l’email. Les identifiants GitHub sont renommables, et un compte renommé ne doit pas entrer en collision avec un nouveau qui reprend l’ancien nom.

01Le sujet correspond déjà à un compte local → ce compte se connecte. Rien d’autre n’est consulté.
02Aucune correspondance, et l’adresse correspond à un compte existant que le fournisseur atteste vérifié → l’identité y est rattachée.
03Ni correspondance ni compte existant → un compte est créé, mais uniquement si l’inscription par SSO est activée.

Une adresse non vérifiée ne rattache jamais et ne crée jamais. Une adresse qu’un fournisseur ne cautionne pas n’est qu’une chaîne saisie chez lui — l’accepter permettrait de revendiquer n’importe quel compte local en enregistrant cette adresse chez un émetteur permissif.

Deux réglages gouvernent la troisième étape, et ils répondent à des questions différentes :

Autoriser l’inscription: Si une connexion SSO peut créer un compte. Désactivé par défaut : activer Google SSO ne doit pas ouvrir l’inscription à toutes les adresses Gmail du monde. Désactivé, le SSO connecte les comptes déjà existants.
Domaines autorisés: Une liste du type acme.com. Vide signifie aucune restriction. Une liste non vide est un filtre strict sur le domaine exact — un sosie comme acme.com.attacker.net ne passe pas.

Le filtre de domaine s’applique à chaque connexion, y compris pour un utilisateur revenant qui s’est connecté hier. Un exploitant qui restreint la liste attend que les personnes exclues cessent d’entrer — pas seulement de s’inscrire.

La création de compte par SSO respecte tout ce que respecte l’inscription locale : le plafond de sièges de la licence, et la validation par un administrateur si l’installation l’exige. « Il est passé par Google » ne contourne pas la présence d’un humain dans la boucle.

Rattacher et détacher

Depuis Réglages → SSO, un compte existant peut rattacher d’autres identités — connexion par mot de passe aujourd’hui, par Google demain, le même compte dans les deux cas. Chaque identité externe correspond à un seul compte local : deux personnes ne peuvent jamais se connecter comme le même utilisateur du fournisseur et aboutir à des endroits différents.

Détacher votre dernière identité est refusé si votre compte n’a pas de mot de passe utilisable — un compte créé par SSO n’en a jamais eu. Définissez un mot de passe d’abord, puis détachez.

Authentification à deux facteurs

Un code à usage unique basé sur le temps (TOTP) issu de n’importe quelle application d’authentification — 1Password, Aegis, Google Authenticator, Bitwarden. L’inscription tient en trois gestes :

01Réglages → Sécurité → Activer le second facteur. Un secret et un QR code apparaissent.
02Scannez-le, puis saisissez les six chiffres affichés. Le secret n’est validé qu’une fois qu’un code correct prouve que l’application est bien configurée.
03Dix codes de secours sont renvoyés. Affichés une seule fois. Conservez-les ailleurs que sur le téléphone qui porte l’authentificateur.

Chaque code de secours porte 80 bits d’entropie et est à usage unique — un code consommé cesse de fonctionner. Les tirets et espaces sont retirés avant comparaison : la façon de le saisir n’a donc pas d’importance.

Dix codes, à usage unique. Perdez à la fois l’authentificateur et les codes, et seul un administrateur plateforme pourra rétablir l’accès au compte. Imprimez-les, ou placez-les dans un gestionnaire de mots de passe sur un autre appareil.

La désactivation exige votre mot de passe et un code valide — une session volée ne suffit pas à couper le second facteur. Se réinscrire suppose de désactiver d’abord : renouveler le secret en place laisserait une fenêtre où l’ancien et le nouveau fonctionnent tous deux.

Les soumissions de code — à la connexion comme sur le formulaire de désactivation — passent par le même verrouillage par compte que les mots de passe. Des codes erronés répétés gèlent le compte pour un temps, au lieu de permettre un forçage illimité sur six chiffres.

Activez-le d’abord sur les comptes détenant apps:env, instances:ssh ou des permissions plateforme. Ce sont ceux où un mot de passe volé coûte des secrets de production ou un shell root — voir rôles et permissions.

Chaque inscription, désactivation et tentative échouée arrive dans le journal d’audit, avec l’adresse IP d’origine.