SSO entreprise (OIDC) & authentification multi-facteurs (MFA)

Emplacement de la configuration

Les administrateurs d'entreprise accèdent à ces paramètres via Paramètres → Entreprise, dans les onglets Méthodes de connexion et Double authentification.

VPN, proxy ou pare-feu d'entreprise

Si vos utilisateurs se connectent derrière un VPN, un proxy d'entreprise ou un pare-feu avec inspection SSL, certains flux du SSO peuvent être bloqués ou altérés (cookie d'état supprimé, domaines d'identité inaccessibles). Le symptôme typique est une connexion qui échoue ou tourne en boucle — alors que le SSO fonctionne hors VPN. Communiquez à votre équipe réseau la matrice des flux réseau pour autoriser les domaines nécessaires sans inspection SSL ni réécriture des cookies.

Méthodes de connexion disponibles

FoxPlan supporte plusieurs approches d'authentification :

• Mot de passe
• Google Sign-in
• Microsoft Sign-in
• SSO entreprise (OIDC)

Important

Les administrateurs d'entreprise conservent toujours la connexion par mot de passe, même lorsqu'elle est désactivée pour l'entreprise. Cela évite de se retrouver verrouillé hors de FoxPlan si le fournisseur d'identité devient indisponible.

Exceptions : conserver le mot de passe pour certains utilisateurs

Lorsque vous basculez votre organisation vers le SSO, vous pouvez désactiver la connexion par mot de passe pour tout le monde sauf une liste d'utilisateurs désignés.

Décochez Mot de passe : un sélecteur « Exceptions : utilisateurs conservant le mot de passe » apparaît alors sous les cases à cocher. Choisissez-y les utilisateurs concernés, puis enregistrez.

Ces utilisateurs continueront de voir le champ mot de passe sur l'écran de connexion, tandis que tous les autres devront passer par le SSO ou la connexion Google/Microsoft.

Cas d'usage typiques :

• Comptes de secours (« break-glass ») en cas de panne du fournisseur d'identité
• Prestataires ou externes absents de votre annuaire d'entreprise
• Migration progressive : basculer les équipes vers le SSO par vagues

astuce

Le sélecteur n'est visible que si la méthode Mot de passe est décochée : tant qu'elle est active, elle s'applique déjà à tout le monde et aucune exception n'est nécessaire.

Options MFA

Les organisations peuvent choisir parmi :

• TOTP (compatible Google Authenticator, Microsoft Authenticator, Okta, Keycloak)
• Vérification par email
• Pas de MFA

Périmètre : à qui s'applique la double authentification

Dès qu'une méthode est sélectionnée (TOTP ou Email), une section « S'applique à » permet de choisir la population concernée :

Option	Effet
Tous les utilisateurs	La double authentification s'impose à toute l'entreprise (comportement par défaut).
Uniquement les utilisateurs listés	Seuls les utilisateurs sélectionnés passent par la double authentification.
Tous les utilisateurs sauf ceux listés	La double authentification s'applique partout, sauf pour les utilisateurs sélectionnés.

Pour les deux derniers modes, un sélecteur permet de désigner les utilisateurs concernés.

Cas d'usage typiques :

• Déploiement progressif : commencer par « Uniquement les utilisateurs listés » avec une équipe pilote, puis basculer sur « Tous les utilisateurs ».
• Renforcement ciblé : n'exiger la double authentification que pour les administrateurs et les profils sensibles.
• Exclusions techniques : dispenser des comptes qui ne peuvent pas répondre à un défi MFA (comptes de service, bornes partagées) via « Tous les utilisateurs sauf ceux listés ».

Le périmètre est appliqué côté serveur : un utilisateur hors périmètre se connecte directement, sans défi MFA, même si une méthode est active pour l'entreprise.

attention

En mode « Tous les utilisateurs sauf ceux listés », chaque utilisateur exclu constitue un affaiblissement du niveau de sécurité. Revoyez cette liste régulièrement.

Flux de connexion

1. L'utilisateur saisit son email et continue
2. FoxPlan identifie l'entreprise associée
3. Les méthodes d'authentification disponibles pour cette organisation s'affichent
4. L'utilisateur choisit Mot de passe ou SSO selon les options activées

Pour les flux par mot de passe, les défis MFA s'appliquent. Les flux SSO délèguent l'authentification au fournisseur d'identité.

Configuration SSO entreprise (OIDC)

FoxPlan supporte les fournisseurs OIDC : Okta, Keycloak, Google, Microsoft et implémentations personnalisées.

Côté fournisseur d'identité :

• Créer une application OIDC de type Web
• URL de redirection : {origin}/login/oauth2/code/{registrationId}
• Collecter Client ID, Client Secret (ou certificat, voir ci-dessous) et Issuer URI

Côté formulaire SSO FoxPlan :

• Sélection du fournisseur
• Nom d'affichage
• Client ID
• Authentification du client : secret partagé ou certificat
• Issuer URI
• Scopes : openid,profile,email
• Attribut username (typiquement sub ou email)
• Toggle d'activation

Authentification du client : secret ou certificat

L'échange du code d'autorisation contre un jeton est le seul appel que FoxPlan adresse directement au fournisseur d'identité, de serveur à serveur. FoxPlan doit s'y identifier, et le champ Authentification du client offre deux manières de le faire.

Secret client (par défaut). Un secret partagé, saisi des deux côtés. C'est le mode historique, et rien ne change pour les configurations existantes : sans choix explicite, elles restent sur ce mode.

Certificat (clé privée). FoxPlan signe une assertion JWT avec une clé privée, et le fournisseur la vérifie avec le certificat public que vous y avez déclaré (private_key_jwt, RFC 7523). Le secret ne circule alors jamais sur le réseau — c'est pourquoi beaucoup de directions informatiques interdisent aujourd'hui les secrets clients.

Deux champs apparaissent alors :

• Certificat client : le certificat X.509 au format PEM. C'est la moitié publique, à téléverser également chez votre fournisseur d'identité (dans Entra ID : Certificates & secrets → Certificates).
• Clé privée : au format PKCS#8 non chiffré, celui qui commence par -----BEGIN PRIVATE KEY-----. Une clé PKCS#1 (BEGIN RSA PRIVATE KEY) ou protégée par mot de passe est refusée avec la commande de conversion à appliquer.

Pour produire une paire :

openssl req -x509 -newkey rsa:2048 -keyout cle.pem -out certificat.pem -days 730 -nodes -subj "/CN=foxplan-sso"
openssl pkcs8 -topk8 -nocrypt -in cle.pem -out cle-pkcs8.pem

Vous déclarez certificat.pem chez le fournisseur et collez cle-pkcs8.pem dans FoxPlan.

La clé privée est chiffrée en base, n'est jamais renvoyée par l'API et n'est jamais réaffichée à l'écran : en modification, laisser le champ vide conserve la clé enregistrée. Le certificat, lui, est public et reste visible.

Un certificat expire

Contrairement à un secret, un certificat porte une date de fin. Passée cette date, le SSO s'arrête net.

L'échéance est donc affichée en permanence : la liste des configurations porte une colonne Authentification qui indique, pour chaque SSO, s'il s'authentifie par secret ou par certificat — et dans ce dernier cas la date d'expiration, en orange dans le mois qui la précède, en rouge une fois passée. Cette date n'est jamais saisie : elle est lue dans le certificat lui-même à chaque affichage, seule source qui ne puisse pas diverger de la réalité. Vérifier la configuration en donne le détail complet, empreinte comprise.

Configuration par fournisseur

Google — Issuer URI : https://accounts.google.com

Microsoft / Azure — Issuer : https://login.microsoftonline.com/{tenantId}/v2.0

Okta — Type Web app avec assignation et politiques d'accès appropriées

Keycloak — Issuer URI du realm, flow Authorization Code configuré

Être prévenu avant l'expiration

L'affichage suppose que quelqu'un aille regarder. FoxPlan prévient donc de lui-même : un courriel part vers les administrateurs de l'entreprise à trois échéances — trente jours, sept jours, puis le jour où le certificat a expiré. Le message nomme le fournisseur concerné, donne la date, et renvoie vers l'écran de configuration.

Chaque palier n'est annoncé qu'une fois : le balayage retient ce qu'il a déjà envoyé. Dès que le certificat est renouvelé — l'échéance repassant au-delà de trente jours — le compteur se réarme tout seul pour le certificat suivant. Aucune action n'est nécessaire.

Si aucun administrateur d'entreprise n'est déclaré, aucun courriel ne part : c'est une raison de plus de tenir cette liste à jour dans les membres de l'entreprise.

Quand la connexion échoue

Un utilisateur dont la connexion SSO échoue revient sur l'écran de connexion avec une phrase qui nomme la cause, et non un code renvoyé par le fournisseur d'identité :

Ce que voit l'utilisateur	Ce qu'il faut faire
Le certificat de connexion a expiré	Renouveler le certificat et le redéposer des deux côtés
Le certificat est inutilisable	Vérifier que la clé privée déposée est bien celle du certificat
Le fournisseur a refusé les identifiants de FoxPlan	Le secret a été changé côté fournisseur, ou le certificat n'y est pas déclaré
Aucune connexion SSO active	La configuration est désactivée ou absente
Le fournisseur a refusé l'accès	Le compte n'est pas autorisé sur l'application côté fournisseur

Le détail technique — message exact du fournisseur, trace complète — reste dans les journaux du serveur, à l'usage du support. L'utilisateur, lui, reçoit une phrase qui lui dit à qui s'adresser.

Vérifier la configuration avant de tester

Chaque configuration de la liste porte un bouton Vérifier la configuration. Il ouvre un rapport qui ne quitte pas l'écran et ne tente aucune connexion :

• les URL à déclarer chez le fournisseur d'identité, avec un bouton copier : l'URL de redirection et l'URL de lancement de la connexion. Ce sont exactement celles que l'application utilisera, inutile de les reconstituer à la main ;
• les contrôles de cohérence : champs obligatoires renseignés, document de découverte lu depuis le serveur, émetteur et points d'accès conformes à ce que publie le fournisseur. En authentification par certificat, le rapport vérifie en plus que la clé privée correspond bien au certificat, affiche l'empreinte SHA-1 — celle que montre la console du fournisseur — et signale un certificat expiré ou proche de l'être.

Trois niveaux : vert quand c'est conforme, orange pour un point à regarder, rouge pour ce qui empêchera la connexion. Le détail affiché à droite de chaque ligne est la donnée brute — URL, statut HTTP, message du fournisseur — celle qu'on recopie au support.

Un contrôle peut être signalé « URL non sondée » : le serveur n'appelle que des adresses publiques en https, la configuration n'est pas en cause.

Ce rapport est en lecture seule : il ne modifie jamais la configuration.

Dépannage

Commencez par Vérifier la configuration : la majorité des échecs de premier paramétrage y apparaissent directement. Vérifiez ensuite ces éléments :

• L'URL de redirection correspond exactement entre IdP et FoxPlan
• La configuration SSO est bien activée
• L'email de l'utilisateur appartient à la bonne entreprise
• Pour Okta/Azure/Keycloak, vérifiez l'assignation et la conformité aux policies
• Pour les utilisateurs Password+MFA, vérifiez l'enrôlement (secret TOTP ou email valide)
• En authentification par certificat, comparez l'empreinte SHA-1 du rapport de vérification avec celle affichée chez le fournisseur : un certificat téléversé puis remplacé sans être redéposé dans FoxPlan est la cause la plus fréquente de rejet de la signature (AADSTS700027 côté Microsoft)