Le 2 avril dernier, Microsoft a définitivement coupé Azure ACS — l’authentification SharePoint par Client ID et Client Secret que presque tout le monde utilisait encore pour les intégrations app-only. Résultat concret : n’importe quel connecteur qui parlait à SharePoint via ce mécanisme s’est retrouvé, du jour au lendemain, face à une exigence de certificat qu’il n’avait jamais eu besoin de gérer.
C’est exactement la situation dans laquelle je me suis retrouvé récemment sur un connecteur SharePoint côté client. Ce qui ressemblait à une simple substitution — un secret contre un certificat — s’est transformé en plusieurs heures d’investigation, avec son lot de pièges franchement pas évidents à deviner à l’avance. Voici le compte-rendu, dans l’ordre où les choses se sont vraiment passées.
Le Mauvais Chemin : le Connecteur HTTP Client
Premier réflexe naturel : rester sur le connecteur HTTP Client, déjà en place, et simplement changer le mode d’authentification. Mauvaise pioche. Son onglet OAuth 2.0 n’expose que trois grant types — Authorization Code, Resource Owner Credentials, et Client Credentials — ce dernier n’acceptant qu’un Client ID et un Client Secret. Aucune option pour signer une assertion JWT avec un certificat.
Piège annexe qui mérite d’être noté : ce connecteur a bien un onglet SSL avec un champ Client SSL Certificate. Il ne sert à rien ici — c’est de l’authentification mTLS au niveau de la poignée de main TLS, un mécanisme totalement différent qui ne génère aucune assertion JWT et ne répond donc pas à ce qu’exige Entra ID.
Le Bon Chemin : le Connecteur REST Client
Boomi a un second connecteur HTTP, REST Client, distinct du précédent, dont l’onglet OAuth 2.0 supporte nativement l’assertion JWT signée par certificat. En sélectionnant Grant Type = Client Credentials, un champ Client Assertion Type apparaît avec le choix entre Client Secret et JWT Token.
Le principe, une fois qu’on choisit JWT Token : au lieu d’envoyer un secret partagé, Boomi construit et signe un JWT avec la clé privée du certificat, puis l’envoie comme preuve cryptographique (client_assertion) à la place du client_secret. Entra vérifie la signature avec le certificat public déjà enregistré sur l’app registration. Le connecteur expose tous les champs nécessaires pour ça : Signature Algorithm, Signature Key, Issuer, Subject, Audience, Expiration, Claim ID Generator, et le thumbprint du certificat.
Sur le papier, une fois ces champs remplis, tout devrait fonctionner. En pratique, quatre pièges distincts m’attendaient, chacun produisant une erreur qui ne ressemblait en rien à sa véritable cause.
La Chronologie des Pièges
| Erreur rencontrée | Cause réelle | Statut |
|---|---|---|
AADSTS900144 — paramètre resource manquant | Confusion entre le endpoint v1 (attend resource) et v2 (attend scope) — vérifier que l’Access Token URL contient bien /v2.0/ | ✅ Résolu |
AADSTS700023 — audience du JWT rejetée | Le claim aud de l’assertion doit être .../{tenantId}/v2.0 — pas l’URL complète du token endpoint, contrairement à ce que suggère la logique la plus intuitive | ✅ Résolu |
| Grant Type “JWT Bearer Token” ≠ Client Credentials | Deux flows OAuth distincts dans Boomi, faciles à confondre — le bon est Client Credentials avec Client Assertion Type = JWT Token | ✅ Résolu |
| 401 muet, sans code AADSTS | Case Preemptive Authentication décochée sur l’onglet Connection — le cycle défi-réponse par défaut d’HttpClient se comporte mal avec un Bearer token | ✅ Résolu |
Le détail qui compte : pourquoi on ne peut pas copier le thumbprint depuis Azure
Un point annexe, mais qui vaut le coup d’œil : le thumbprint affiché dans le portail Entra (Certificates & secrets) est en SHA-1, en hexadécimal. Boomi — comme la documentation Microsoft à jour — attend du SHA-256, encodé en base64url, calculé sur le certificat au format DER. Ce ne sont pas deux présentations de la même valeur : deux hashs mathématiquement indépendants sur les mêmes octets. Impossible de copier l’un pour obtenir l’autre — il faut le recalculer :
openssl x509 -in cert.cer -inform DER -outform DER \
| openssl dgst -sha256 -binary \
| openssl base64 -A \
| tr '+/' '-_' | tr -d '='Autre nuance dans le même registre : la documentation Microsoft actuelle spécifie PS256 comme algorithme de signature, pas RS256 comme le suggèrent encore la plupart des tutoriels en ligne. Heureusement, RS256 reste toléré en pratique pour la rétrocompatibilité — mais si l’authentification échoue sans raison apparente, c’est un des premiers points à vérifier.
Une fausse piste instructive : Sites.Selected existe en double
Pendant l’investigation, j’ai suivi une piste qui s’est révélée être un faux positif dans ce cas précis, mais qui vaut la peine d’être connue : la permission Sites.Selected existe en réalité comme deux entrées distinctes dans les API permissions d’une app registration — une sous Microsoft Graph, une autre séparée sous l’API SharePoint (“Office 365 SharePoint Online”). Consentir l’une ne consent pas l’autre. Ce n’était pas la cause de mon problème — les deux étaient déjà correctement configurées côté client — mais c’est le genre de piège qui mérite une vérification systématique avant d’aller chercher plus loin.
La Configuration Finale, pour Référence
Pour éviter à quelqu’un d’autre de reparcourir les quatre étapes ci-dessus, voici la configuration complète qui fonctionne, une fois tous les correctifs appliqués.
Onglet OAuth 2.0 :
| Champ | Valeur |
|---|---|
| Grant Type | Client Credentials |
| Client Assertion Type | JWT Token |
| Signature Algorithm | PS256 (RS256 toléré en repli) |
| Signature Key | composant Certificat Boomi (import du .pfx) |
| Issuer (iss) | <ClientId> |
| Subject (sub) | <ClientId> (identique à Issuer) |
| Audience (aud) | https://login.microsoftonline.com/<TenantId>/v2.0 |
| Access Token URL | https://login.microsoftonline.com/<TenantId>/oauth2/v2.0/token |
| Expiration (exp) | 600 |
| Claim ID Generator (jti) | UUID |
| X.509 Certificate SHA-256 Thumbprint | calculé via la commande openssl ci-dessus |
| Scope | https://<tenant>.sharepoint.com/.default |
Onglet Connection :
| Champ | Valeur |
|---|---|
| Authentication Type | OAuth 2.0 |
| Preemptive Authentication | ☑ Coché — sans ça, retour à la case départ malgré une config OAuth par ailleurs impeccable |
Le correctif a fonctionné : une fois l’authentification préemptive activée, la connexion s’est établie sans accroc. Au final, quatre causes distinctes, chacune méconnaissable derrière son symptôme — de quoi rappeler qu’un 401 générique ne dit jamais grand-chose sur sa véritable origine. Si vous êtes en train de migrer un connecteur similaire et que vous butez sur un point que cet article ne couvre pas, n’hésitez pas à me contacter.