Skip to content
Yassir Halaoui
EN
Read in English

Compétence

Sécurité des API et intégration d’entreprise : OAuth 2.0, mTLS, SOAP

La moitié de l’ingénierie en entreprise consiste à parler en sécurité au système de quelqu’un d’autre : un processeur de cartes en SOAP, le SSO d’une banque, une API gateway, les webhooks d’un prestataire de paiement. C’est la moitié dont j’ai fait ma spécialité.

En bref

Yassir Halaoui construit des intégrations sécurisées pour des systèmes régulés : OAuth 2.0 et OpenID Connect avec Okta, JWT, contrôle d’accès par rôles, mTLS et WS-Security sur SOAP, API gateways comme Apigee et Azure API Management, et webhooks. Chez Pluxee, il intègre des fichiers chiffrés par un HSM, reçus en SOAP et sécurisés par mTLS et WS-Security.

Où je l'ai utilisée

  1. Pluxee · depuis 2025

    Intégration de fichiers chiffrés par le HSM d’un processeur de cartes, reçus en SOAP avec mTLS et WS-Security, et traités de façon asynchrone et idempotente à partir de notifications webhook.

  2. Société Générale · 2022 à 2024

    Intégration du SSO et de la gestion des identités de la banque pour l’authentification et l’administration des utilisateurs, et conception de rôles, permissions et contraintes fins dans le cadre du processus secure by design de la banque.

  3. CIH Bank · 2017 à 2022

    Conception avec le fournisseur d’une API de dépôt d’espèces aux distributeurs, rédaction du contrat d’API, et exposition du service derrière une API gateway qui sécurisait les appels REST.

  4. Conseil · 2022

    Utilisation d’Apigee comme API gateway d’une plateforme de location automobile.

  5. Kempt, RevealTogether, TheQuizMaster

    Paiements et webhooks Stripe dans les trois produits, dont des clés de licence émises par un webhook Stripe pour Kempt.

Tout ce que couvre ce domaine

Identité et accès
  • OAuth 2.0
  • OpenID Connect
  • Okta
  • JWT
  • RBAC
  • SSO
Sécurité du transport et des messages
  • mTLS
  • WS-Security
  • SOAP
  • Signature XML
Gateways et contrats
  • Apigee
  • Azure API Management
  • OpenAPI
  • BFF
  • REST
Paiement et webhooks
  • Stripe
  • PayPal
  • Webhooks
  • Synchronisation Salesforce
Pratiques
  • Secure by Design
  • Idempotence
  • Pagination keyset

En profondeur

Trois couches souvent confondues

Le mTLS prouve quelle machine appelle. WS-Security prouve qui a envoyé un message et que personne ne l’a modifié en route. Le chiffrement du contenu garde un fichier scellé jusqu’au seul composant qui détient la clé. Un partenaire qui exige les trois ne fait pas de zèle.

Un jeton valide n’est pas une autorisation

Le constat que je fais le plus souvent en revue : un endpoint qui vérifie le jeton sans jamais vérifier si cet utilisateur a le droit de toucher à cet enregistrement. Le contrôle de rôle dit quel type d’utilisateur vous êtes. Le contrôle de propriété dit si ce compte est le vôtre. Il faut les deux, sur chaque endpoint qui reçoit un identifiant.

Un webhook est une garantie de livraison

Répondre 200 seulement une fois l’événement enregistré, et une erreur 5xx sinon, pour que l’émetteur réessaie. Un catch-all défensif qui répond toujours 200 jette en silence les retries de l’émetteur, et vos données avec.

Questions

Pouvez-vous intégrer un web service SOAP avec mTLS et WS-Security dans Spring Boot ?

Oui, j’en fais tourner un en production. Sur Spring Boot 3, cela veut dire HttpClient 5 avec un keystore et un truststore séparés pour le mTLS, des intercepteurs WSS4J pour la signature et l’horodatage, et un handler de webhook qui enregistre puis répond avant tout traitement.

Client credentials OAuth ou mTLS entre services ?

Les partenaires régulés demandent en général les deux : le mTLS sur la connexion, pour qu’un jeton volé soit inutile seul, et un jeton court et limité dans la requête pour l’autorisation. Chacun, isolé, laisse une faille.

Pouvez-vous configurer Spring Security avec OIDC et Okta ?

Oui : un resource server sans état qui refuse par défaut, valide l’émetteur, l’expiration et l’audience, associe les claims à des rôles, et vérifie la propriété dans le service plutôt qu’uniquement à la gateway.

Gérez-vous la rotation des certificats mTLS ?

Oui. Séparer le truststore du keystore, faire confiance aux deux chaînes pendant un chevauchement de plusieurs semaines, faire tourner un sens à la fois, et alerter sur le certificat réellement présenté sur le réseau.

Notes de terrain

Réalisations

Compétences liées