Authentifier une API B2B hors annuaire interne

Authentifier une API B2B hors annuaire interne

Une interface EDI (Electronic Data Interchange) ou API (Application Programming Interface) B2B relie deux périmètres d’identité qui ne fusionneront pas. Le partenaire n’est pas un utilisateur interne temporairement mal rangé dans l’annuaire : c’est une organisation externe, avec ses propres administrateurs, ses propres incidents et parfois un coffre-fort à secrets dont personne ne retrouve la notice.

Explication de la marmotte

Un échange entre deux entreprises ressemble à une livraison entre deux sites fermés : il faut savoir qui arrive, ce qu’il a le droit de déposer ou d’emporter, puis retirer son accès quand la relation s’arrête. Sans registre, les anciens badges restent souvent actifs bien après le dernier carton.

→ Lire l’explication complète de la marmotte

mTLS et certificats clients pour l’identité d’organisation

Le mTLS (mutual Transport Layer Security) authentifie simultanément le serveur et le client pendant l’établissement de la connexion chiffrée. Le serveur accepte le certificat client seulement si sa chaîne remonte à une autorité de certification autorisée, si sa période de validité est respectée et si ses contraintes d’usage permettent l’authentification client.

C’est le bon mécanisme pour identifier un système partenaire stable, notamment pour un flux EDI à forte criticité ou une API exposée derrière une passerelle. Il apporte une preuve cryptographique de possession d’une clé privée, sans transmettre un secret partagé à chaque requête. Il réduit aussi le risque de rejeu d’un jeton volé sur une autre connexion, à condition de lier réellement le jeton au certificat lorsque les deux mécanismes coexistent.

Le compromis est brutal : mTLS donne une identité d’organisation robuste, mais impose une PKI (Public Key Infrastructure) inter-organisationnelle exploitable. Une autorité de certification privée par partenaire ne devient pas une stratégie parce qu’un fichier de configuration accepte plusieurs autorités. Elle devient une collection de pannes différées, avec un vernis PEM.

Le certificat doit identifier un client technique précis, pas une entreprise entière. Un certificat unique partagé par tous les systèmes d’un partenaire rend impossible l’attribution d’un incident et transforme la révocation en coupure générale. Prévoir au minimum une paire de clés par environnement, par application partenaire et, lorsque l’architecture le justifie, par zone réseau.

L’autorisation ne doit pas être dérivée du seul nom figurant dans le certificat. Le certificat répond à « quelle identité cryptographique présente cette connexion ? ». Il ne répond pas à « peut-elle soumettre une facture, consulter un stock ou appeler une opération de remboursement ? ». Une table d’autorisation côté passerelle doit associer l’empreinte du certificat, ou son sujet contrôlé, à des ressources et opérations explicitement définies.

Les fondations de ce mécanisme sont détaillées dans PKI et TLS. Sans gouvernance des émetteurs, inventaire des certificats et supervision des dates d’expiration, mTLS n’est pas une barrière : c’est un minuteur caché dans un flux de production.

OAuth 2.1 et credentials machine-à-machine

OAuth 2.1, évolution du cadre OAuth (Open Authorization), permet à un client technique d’obtenir un jeton d’accès limité auprès d’un serveur d’autorisation. Le flux client_credentials est conçu pour un appel machine-à-machine : il n’y a ni navigateur, ni utilisateur humain, ni consentement à bricoler dans une page de connexion.

Pour les nouvelles API B2B, la position à retenir est la suivante : préférer OAuth avec un jeton court, des portées limitées et une authentification forte du client. Associer OAuth à mTLS pour les partenaires critiques ou à haut privilège. OAuth porte alors l’autorisation, mTLS ancre l’identité du client. Ce n’est pas du « zero trust » saupoudré sur une slide, c’est une séparation concrète entre preuve d’identité et droit d’accès.

Une portée, ou scope, doit décrire une capacité métier limitée : orders.submit, invoices.read, catalog.read. Une portée api.full_access remplace une politique d’autorisation par un aveu de fatigue. Les portées doivent être contrôlées par opération et par ressource, pas seulement lors de l’émission du jeton.

Un JWT (JSON Web Token) signé permet à une passerelle de vérifier localement le jeton, mais sa révocation est limitée avant expiration. Un jeton signé de douze heures conserve ses droits pendant douze heures après l’offboarding, sauf mécanisme complémentaire. Pour les opérations sensibles, utiliser des jetons de durée courte, typiquement quelques minutes, ou des jetons opaques validés par introspection auprès du serveur d’autorisation. Le choix dépend de la tolérance à la révocation différée et de la disponibilité acceptable du service d’autorisation.

Les clés API statiques restent tolérables pour un flux transitoire, à faible privilège et avec rotation automatisée vérifiée. Elles ne constituent pas une cible d’architecture B2B pérenne. Une clé partagée est fréquemment copiée dans des variables d’environnement, des scripts d’intégration, des tickets et des coffres partenaires. Quand elle fuit, on sait rarement quel système l’a utilisée, seulement quel partenaire doit subir la coupure.

La gestion des identités et de leurs attributs reste le sujet central, même hors annuaire interne : architecture des identités fournit le cadre de gouvernance nécessaire.

Exemple OAuth client credentials avec mTLS

Cet exemple demande un jeton lié à un certificat client, puis appelle une API. Le serveur d’autorisation doit vérifier le certificat présenté, enregistrer son empreinte pour le client concerné et n’émettre que les portées autorisées.

# Le certificat et la clé privée appartiennent au client technique partenaire.
# La clé doit provenir d'un coffre-fort ou d'un module matériel, jamais du dépôt Git.
export CLIENT_CERT="./partner-prod-client.crt"
export CLIENT_KEY="./partner-prod-client.key"

# Obtenir un jeton d'accès pour une capacité métier limitée.
ACCESS_TOKEN="$(curl --fail --silent --show-error \
  --cert "$CLIENT_CERT" \
  --key "$CLIENT_KEY" \
  --data "grant_type=client_credentials" \
  --data "scope=orders.submit" \
  https://auth.example.net/oauth/token \
  | jq --raw-output '.access_token')"

# Appeler l'API avec le même certificat afin de conserver la liaison mTLS.
curl --fail --silent --show-error \
  --cert "$CLIENT_CERT" \
  --key "$CLIENT_KEY" \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{"reference":"PO-4821","lines":[{"sku":"A-17","quantity":4}]}' \
  https://api.example.net/v1/orders

Le serveur de ressources doit vérifier l’émetteur du jeton, son audience, son expiration et sa portée. Accepter un jeton parce que sa signature est valide sans vérifier son audience revient à accepter un badge de cantine pour ouvrir une salle serveur. La cryptographie a fait son travail, l’architecture l’a contournée.

Le certificat et le jeton doivent être journaux avec leur identifiant technique, jamais avec la clé privée, le jeton complet ou l’en-tête Authorization. Les traces utiles contiennent l’empreinte du certificat, l’identifiant de client, la portée, l’opération, la ressource visée, le résultat et un identifiant de corrélation.

Fédération ponctuelle entre organisations

La fédération convient lorsqu’un partenaire possède déjà un fournisseur d’identité capable d’émettre des assertions signées et que l’organisation consommatrice peut contrôler cet émetteur. OpenID Connect (OIDC) permet notamment d’accepter une assertion portant une identité de charge de travail ou une identité humaine, sans créer localement un secret durable par application.

Cette approche réduit la distribution de secrets, mais déplace la dépendance vers la disponibilité et la gouvernance de l’émetteur partenaire. Il faut enregistrer explicitement les émetteurs acceptés, les audiences autorisées, les clés publiques de signature, les algorithmes permis et les règles de rotation. Accepter toute assertion provenant d’un domaine partenaire est trop large : les sous-domaines, tenants ou applications internes du partenaire ne portent pas automatiquement les mêmes droits.

La fédération ponctuelle devient préférable quand le partenaire opère déjà une identité de charge de travail mature, que les échanges sont nombreux et que les deux parties peuvent gérer une relation de confiance formelle. Pour un partenaire occasionnel, mTLS avec autorisation locale reste souvent moins fragile. La sophistication n’est pas un objectif, seulement une facture mieux présentée.

Révocation, offboarding et registre des accès B2B

La fin d’un contrat doit déclencher une révocation technique vérifiable. Désactiver une adresse de contact ou fermer un ticket ne retire ni un certificat, ni une clé API, ni un client OAuth, ni une règle de pare-feu. Ces objets n’ont pas lu le contrat.

Un registre centralisé des accès B2B doit contenir, pour chaque partenaire et chaque environnement :

• le propriétaire métier et le propriétaire technique ;
• les flux, points d’entrée et plages réseau autorisées ;
• les identifiants OAuth, empreintes de certificats et clés API ;
• les portées, ressources et limites de débit accordées ;
• l’émetteur de certificats, la date d’expiration et la procédure de renouvellement ;
• la procédure d’urgence, le délai de coupure attendu et la preuve de désactivation.

La révocation d’un certificat via une CRL (Certificate Revocation List) ou OCSP (Online Certificate Status Protocol) ne ferme pas les sessions TLS déjà établies. Les connexions persistantes doivent être coupées côté passerelle lors d’une révocation urgente. De même, supprimer un client OAuth n’invalide pas nécessairement les jetons déjà émis : prévoir une durée de vie courte, une liste de blocage ou une introspection selon le niveau de risque.

L’offboarding doit exécuter dans un ordre contrôlé : bloquer les nouvelles authentifications, révoquer les certificats et secrets, supprimer les autorisations, fermer les sessions persistantes, retirer les règles réseau, vérifier les journaux après coup, puis archiver les preuves. Les sauvegardes contiennent parfois des secrets historiques : les restaurations doivent réappliquer l’état de révocation actuel, sinon un incident ancien ressort de terre avec une clé encore vivante. Très mauvais film, très fréquent.

La supervision doit alerter sur les expirations de certificats, les échecs répétés d’authentification, les portées anormales, les appels depuis une origine inattendue et toute utilisation après date de fin contractuelle. Les mécanismes cryptographiques sont documentés dans les fondations de la cryptographie appliquée, mais aucun certificat ne remplace un inventaire des droits ni un processus de sortie.

🐝 Ce qui arrive si on s’en passe

Sans identité technique distincte par partenaire et par environnement, la ruche accepte des visiteurs qu’elle ne sait plus nommer. La réponse à incident perd sa granularité : couper un flux suspect revient à suspendre l’ensemble des échanges d’une organisation, y compris les commandes légitimes en cours, avec des retraitements manuels et des ruptures de séquence sur les flux EDI. La preuve d’origine disparaît aussi : en cas de litige commercial sur une facture ou un bon de commande soumis, aucun élément technique ne permet de rattacher l’écriture à un appelant précis, et la non répudiation se réduit à une déclaration. Enfin, sans droits distincts, les quotas, limites de débit et seuils de détection s’appliquent à un bloc indifférencié : un comportement anormal se dilue dans le trafic normal du même identifiant et passe sous le seuil d’alerte.

🦫 Explication de la marmotte 🍫

Quand deux entreprises échangent des données, chacune doit reconnaître le système de l’autre sans ajouter ses employés dans son propre annuaire. Une première méthode utilise un certificat : un fichier d’identité lié à une clé privée gardée secrète. Pendant la connexion, le serveur vérifie que le certificat est encore valable et qu’il vient d’un émetteur accepté. Cela prouve quel système se connecte, mais pas ce qu’il a le droit de faire.

Les droits sont donc gérés séparément. Un serveur d’autorisation peut remettre un jeton temporaire après avoir vérifié l’identité du système appelant. Ce jeton indique les actions permises, par exemple envoyer une commande ou lire un catalogue. Le service qui reçoit la demande vérifie la signature du jeton, sa date de fin, son destinataire et les droits demandés avant d’exécuter l’action.

Une clé partagée peut aussi identifier un partenaire, mais elle est souvent copiée dans trop d’endroits. Si elle est volée, il devient difficile de savoir quel système l’utilise. Les certificats et jetons courts limitent mieux ce problème.

À la fin du contrat, il faut désactiver toutes les identités techniques, supprimer les droits, fermer les connexions déjà ouvertes et retirer les règles réseau. Révoquer seulement un certificat ou supprimer seulement un compte ne suffit pas. Un registre central doit lister chaque accès accordé au partenaire, sinon certains accès survivent par oubli.

À lire aussi

• Gérer les accès externes des prestatairesConcevoir des accès externes, portails partenaires et fédérations inter-entreprises sans perdre la visibilité sur les identités tierces et la responsabilité des autorisations.
• OIDC, SAML et OAuth 2.1 en fédérationComparer OIDC et SAML, déployer OAuth 2.1 sans confusion, et gouverner la durée de vie, la portée et la révocation des jetons.
• Partage de données inter-organisations par APIPartager des données entre organisations exige des contrats exécutables, des API limitées et une confiance technique strictement bornée.
• Attaque par confusion de scope OAuthDémonstration d’une élévation de périmètre OAuth causée par des scopes trop larges et exploitation d’un jeton d’accès compromis.

Pages voisines

La citent

• Gérer les accès externes des prestataires
• Comment sécuriser les webhooks entrants
• Partage de données inter-organisations par API

Authentifier une API B2B hors annuaire interne

Elle cite

• Pièges OAuth 2.1 : PKCE, redirections et scopes
• CRL ou OCSP pour révoquer un certificat
• Mettre en place la fédération d’identité de charge