Configurer les fournisseurs d’identité

Contrôle d’accès explique ce que fait un fournisseur. Cette page en est le câblage : les valeurs exactes que chacun demande, et où les trouver.

L’URI de redirection d’abord

Chaque fournisseur, sans exception, a besoin d’une valeur enregistrée de son côté : l’URL vers laquelle il renvoie l’utilisateur après la connexion.

Le tableau de bord affiche la valeur exacte sur chaque fournisseur que vous ouvrez, sous Accès → Connexion, avec un bouton de copie. Utilisez-le — ne la retapez pas.

Microsoft — comptes professionnels ou scolaires

Utilisez le fournisseur Entra ID. Il couvre les comptes hébergés dans un annuaire Microsoft (vous@votre-entreprise.com), pas les adresses personnelles Outlook ou Hotmail.

1. Dans le portail Azure, allez dans Microsoft Entra ID → Inscriptions d’applications → Nouvelle inscription.
2. Sous URI de redirection, choisissez Web et collez l’URL de callback du tableau de bord.
3. Copiez l’ID d’application (client) et l’ID de répertoire (locataire) depuis la page de vue d’ensemble.
4. Sous Certificats et secrets → Nouveau secret client, créez un secret et copiez sa valeur immédiatement : Azure ne la réaffiche jamais.
5. Dans ConnXL, ajoutez le fournisseur Entra, collez l’ID client et l’ID de locataire, et pointez le secret client vers votre propre coffre.

Qui peut se connecter est un choix distinct sur ce fournisseur :

• Uniquement mon organisation Microsoft — l’émetteur est épinglé à votre locataire. Toute personne extérieure est refusée avant l’examen de toute autre règle.
• N’importe quelle organisation Microsoft — accepte les annuaires d’autres entreprises, sous réserve de vos règles d’audience. Cela exige deux réglages dans votre inscription d’application que ConnXL ne peut ni définir ni détecter : l’inscription doit accepter les comptes de n’importe quel annuaire organisationnel (multi-tenant), et demander la revendication facultative xms_edov sur le jeton d’accès (Configuration du jeton → Ajouter une revendication facultative). Sans le premier, Microsoft refuse lui-même les connexions externes ; sans le second, toute connexion est refusée de notre côté, car cette revendication est le seul signal qu’une adresse e-mail appartient bien à la personne qui la présente.

Microsoft — comptes personnels

Utilisez le fournisseur Compte personnel Microsoft pour les adresses outlook.com, hotmail.com et live.com. Elles ne figurent dans aucun annuaire Entra, donc le fournisseur Entra ne les acceptera jamais.

La configuration est identique à la précédente, à une différence près : à Nouvelle inscription, choisissez comme types de comptes pris en charge Comptes personnels Microsoft uniquement (ou « n’importe quel annuaire organisationnel et comptes personnels Microsoft » si vous voulez les deux populations). Il n’y a pas d’émetteur à saisir : tous les comptes personnels Microsoft résident dans un annuaire unique détenu par Microsoft, et ConnXL épingle cet émetteur pour vous.

Microsoft — tout compte

Utilisez le fournisseur Microsoft (tout compte) lorsque vos utilisateurs mêlent annuaires professionnels/scolaires et comptes personnels, et que vous voulez un seul bouton de connexion pour tous. Il n’y a ni tenant ni émetteur à saisir : la connexion passe par le point de terminaison common de Microsoft, et ConnXL vérifie l’émetteur de chaque jeton par rapport au tenant dans lequel ce jeton a été émis.

La configuration reprend la même inscription d’application que ci-dessus, avec deux réglages tous deux obligatoires (ConnXL ne peut ni les définir ni les détecter, et une erreur sur l’un échoue comme une erreur Microsoft opaque) :

1. Lors de Nouvelle inscription (ou ensuite sous Authentification → Types de comptes pris en charge), choisissez Comptes dans un annuaire d’organisation quelconque et comptes personnels Microsoft. Tout choix plus restreint fait que Microsoft lui-même refuse l’une des deux classes de comptes.
2. Sous Configuration du jeton → Ajouter une revendication facultative → ID, ajoutez xms_edov. Les emails des comptes professionnels ne sont acceptés que lorsque Microsoft atteste le propriétaire du domaine ; sans cette revendication, toute connexion avec un compte professionnel est refusée de notre côté (les comptes personnels ne sont pas concernés : leur adresse est l’identité vérifiée du compte).

Google

Utilisez le fournisseur Google. Il n’y a pas d’émetteur à saisir : Google n’en a qu’un, partagé par tous les comptes Google.

1. Dans la console Google Cloud, allez dans API et services → Identifiants → Créer des identifiants → ID client OAuth.
2. Type d’application Application Web ; ajoutez l’URL de callback sous URI de redirection autorisés.
3. Copiez l’ID client et le secret client.

L’équivalent du choix « qui peut se connecter » de Microsoft vit du côté de Google, sous Écran de consentement OAuth → Type d’utilisateur :

• Interne — uniquement les comptes de votre organisation Google Workspace.
• Externe — n’importe quel compte Google sur internet. Tant que l’application est en Test, vous êtes limité à 100 utilisateurs de test nommés ; la publication lève cette limite.

Tout autre fournisseur (OIDC générique)

Utilisez le fournisseur OpenID Connect pour tout le reste. Il est illimité : connectez Okta et Auth0 et votre propre Keycloak côte à côte, chacun avec son bouton de connexion.

Il lui faut trois choses : l’URL de l’émetteur, un ID client et un secret client. ConnXL lit le document /.well-known/openid-configuration de l’émetteur pour découvrir les endpoints d’autorisation, de jeton et JWKS — vous ne les saisissez jamais.

L’émetteur doit être une URL https:// avec un hôte ; un simple nom de domaine est refusé. Le sélecteur Configurer pour, à côté du champ, adapte l’exemple à la forme de votre fournisseur :

Tout autre fournisseur conforme au standard fonctionne de la même façon : s’il publie un document de découverte, ConnXL sait l’utiliser.

Portées

Laissez la liste des portées vide, sauf si votre fournisseur en exige plus que les valeurs par défaut. ConnXL demande toujours ce qu’il faut pour identifier l’utilisateur ; les portées supplémentaires ne servent que lorsque votre IdP en exige une explicite pour livrer la revendication e-mail.

Sécurité au niveau des lignes (échange de jeton)

Tout ce qui précède sert à connecter quelqu’un. Cette section porte sur la suite : faire descendre cette identité jusqu’à votre propre base de données, pour qu’une requête renvoie ses lignes et celles de personne d’autre.

Le mode d’authentification Échange de jeton de connexion d’une connexion HTTP rend cela possible. Au lieu de transmettre le jeton Microsoft tel quel, l’agent émet un JWT de courte durée à partir de l’identité qu’il vient de valider, le signe avec un secret que vous fournissez, et l’envoie comme bearer token sur chaque requête que fait la fonction.

Le jeton émis porte sub, email et name de l’utilisateur Excel connecté, plus role, aud, iss, iat et exp. PostgREST — l’API REST que Supabase génère au-dessus de votre base de données — et Hasura acceptent exactement cette forme, si bien que vos politiques de Row-Level Security s’appliquent par utilisateur : chaque requête issue d’une cellule arrive au nom de la personne qui a tapé la formule, et non d’un unique compte de service partagé.

Lequel des deux modes utilisateur choisir

• user_token — transmission simple. Choisissez-le quand votre API valide elle-même les jetons Microsoft : elle a déjà l’émetteur, l’audience et les clés de signature configurés, et lit l’identité de l’appelant directement dans le jeton que l’agent transmet.
• user_token_exchange — échange de jeton. Choisissez-le quand votre API valide ses propres JWT et ignore tout de Microsoft : PostgREST, Supabase, Hasura, ou tout service qui vérifie un secret HS256 partagé. L’agent fait le pont entre les deux mondes.
• Les deux modes envoient l’identifiant sous la forme Authorization: Bearer <token>. Si votre API le lit dans un autre en-tête, indiquez ce nom dans le champ userTokenHeader de la connexion : le jeton est alors envoyé brut dans cet en-tête, sans préfixe Bearer. Laissez le champ vide pour le comportement par défaut.

Recette : des lignes par utilisateur depuis Supabase

1. Repérez le secret de signature. Dans votre tableau de bord Supabase, allez dans Project Settings → API → JWT Secret. C’est le secret avec lequel PostgREST vérifie chaque jeton reçu.
2. Stockez-le comme référence. Placez la valeur dans votre propre coffre et pointez-y le champ exchangeSecret de la connexion — secret://env/SUPABASE_JWT_SECRET, ou l’un des autres backends listés sous Connexions. La valeur elle-même n’atteint jamais ConnXL.
3. Créez la connexion. Type HTTP API, URL de base https://<project-ref>.supabase.co/rest/v1, authentification Échange de jeton de connexion, audience authenticated.
4. Ajoutez l’en-tête apikey. PostgREST attend la clé anon de votre projet sur chaque requête, en plus du bearer token. Ajoutez-la comme en-tête supplémentaire sur la connexion — nom apikey, valeur la clé anon, là encore sous forme de référence secret://. Sans elle, Supabase rejette l’appel avant même d’examiner le JWT.
5. Écrivez la politique. Activez RLS sur la table et adossez-la à une revendication du jeton émis :

create policy "own rows" on documents for select using (auth.jwt()->>'sub' = user_id);

Utilisez plutôt auth.jwt()->>'email' quand vos lignes sont indexées sur l’adresse e-mail et non sur le subject id du fournisseur.

Les champs de l’échange

Quand la connexion ne fonctionne pas

• « redirect_uri mismatch » — l’URL enregistrée ne correspond pas à celle qu’affiche le tableau de bord, caractère pour caractère. Recopiez-la.
• « redirect_uri mismatch » signalant http:// au lieu de https:// (Entra l’affiche comme AADSTS500112) — le TLS se termine sur un équilibreur de charge ou un proxy inverse devant l’agent, et l’agent ne fait pas confiance aux en-têtes transférés par défaut. Définissez CONNXL_TRUSTED_PROXY=1 sur l’hôte de l’agent pour que le callback soit construit en https://.
• La connexion réussit mais le complément vous refuse quand même — l’authentification a fonctionné, pas l’autorisation. Vérifiez les domaines autorisés/refusés et l’audience dans Contrôle d’accès.
• Toutes les connexions Entra échouent en mode « n’importe quelle organisation » — la revendication facultative xms_edov manque dans l’inscription d’application.
• Rien ne se passe au clic sur le bouton de connexion — l’agent doit servir un HTTPS de confiance ; Excel refuse de charger un complément, ou sa fenêtre de connexion, depuis un hôte non fiable.