Pourquoi choisir une plateforme unique : la vision d'un ingénieur sur l'unification de la vérification d'identité, de la lutte contre la fraude et de l'authentification

Série de blogs sur l'ingénierie · Le premier d'une nouvelle série mettant en avant les ingénieurs de Prelude sur la manière dont le produit est réellement construit

Entretien avec Loïc Madiès, ingénieur backend senior chez Prelude.

Avant d'intégrer Prelude, je faisais partie de l'équipe d'authentification d'un site de commerce électronique en France. La fraude était encore une composante majeure du travail.

Sur le papier, la stack était plutôt cohérente. Adresse e-mail et mot de passe, OTP pour l'authentification multifacteur, et quelques fournisseurs de connexion via réseaux sociaux. En dessous : DataDome pour gérer le trafic des bots, Vonage pour la délivrance des codes OTP, et une solution d'authentification développée en interne. Trois outils pour un seul but : permettre à un utilisateur d'accéder à la plateforme, mais aucun d'entre eux ne communiquait avec les autres. Les comptes frauduleux finissaient par être signalés par des modèles analysant les comportements après coup, mais à ce moment-là, l'intrus était déjà dans la place. 

Je n'avais aucune visibilité réelle sur ce qui se passait concrètement sur le moment. Ce manque de visibilité, et le fait qu'une plateforme conçue pour partager des signaux entre ces différentes briques me semblait particulièrement intéressante, expliquent en partie mon choix de rejoindre Prelude.

Trois outils, un seul but, aucun contexte partagé

C'est le point qu'il convient de nommer précisément : chacun de ces trois outils faisait correctement son travail, tout en passant à côté de l'essentiel.

L'authentification en soi représente déjà une surface d'attaque importante, mais elle n'est pas vraiment conçue pour détecter la fraude ; elle se limite généralement à vérifier si le mot de passe est correct, à compter le nombre de tentatives et à appliquer ce type de limitation du débit. Un outil antibot peut constater que le volume de tentatives provenant d'une adresse IP ou d'un pays spécifique est un peu élevé, mais il ne peut pas déterminer s'il s'agit réellement d'un comportement suspect ou d'un trafic normal, du moins pas sans les données relatives au numéro de téléphone fournies par la vérification.

Sans contexte partagé, un système peut détecter qu'un accès ressemble à celui d'un robot tout en le laissant passer comme une connexion normale et non signalée. 

Dès que l'on parvient à injecter les informations issues de l'anti-bot ou de la vérification dans le flux d'authentification, on peut identifier des schémas que ni l'un ni l'autre ne détecteraient seuls. Un mot de passe dangereux, un e-mail suspect, un nombre anormalement élevé de tentatives provenant d'un même pays dans un laps de temps très court : aucun de ces éléments n'est rédhibitoire en soi.

En les associant à l'historique du numéro de téléphone et de l'appareil, ils constituent un signal beaucoup plus clair. Et si le schéma de rafraîchissement d'une session affiche une adresse IP différente à chaque tentative, c'est un indicateur fort de l'utilisation d'un proxy résidentiel. Encore une fois, c'est le genre de chose que l'on ne remarque que lorsque l'on croise les signaux d'authentification et de fraude.

Le partage de ce contexte est bénéfique pour la sécurité et, de manière tout aussi directe, pour l'utilisateur : c'est ce qui lui évite de devoir s'authentifier à nouveau inutilement parce que le système sait déjà ce qui a été vérifié.

Ce n'est pas un ajout tardif. C'était le projet dès le premier jour

Certains s'imaginent parfois qu'une telle unification est greffée après coup, comme si trois produits distincts à l'origine avaient été connectés plus tard. 

Ce n'est pas du tout comme cela que ça s'est passé. 

Le partage des signaux entre ces différents produits était la vision de l'entreprise dès le départ : déléguer l'onboarding et la confiance à un seul acteur plutôt qu'à plusieurs, précisément pour que l'information puisse circuler entre eux.

L'objectif était de permettre aux clients de se concentrer sur leur propre activité plutôt que de gérer eux-mêmes les utilisateurs malveillants, et un acteur unique gérant l'ensemble de ces aspects est bien mieux positionné pour détecter plus d'anomalies, avec moins de faux positifs, que trois systèmes déconnectés ne pourraient jamais le faire.

J'ai commencé par travailler spécifiquement sur l'authentification, sans trop me soucier de la fraude, tout simplement parce qu'il y avait énormément de choses à construire.

Une fois les fonctionnalités de base en place, je me suis également tourné vers la lutte contre la fraude et la vérification, et c'est là que l'interconnexion s'est faite pour moi : les schémas que j'ai découverts du côté de la fraude (le blocage du SMS pumping, puis des bots, puis du détournement de compte) ont directement influencé le comportement de l'authentification, car à ce moment-là, c'était la même personne et le même signal qui alimentaient les deux aspects.

L'exemple concret le plus parlant : Les Refresh Tokens

S'il y a un détail technique qui illustre cette approche mieux que n'importe quel discours philosophique, c'est bien celui-ci.

Dans une architecture classique développée en interne, si quelqu'un dérobe un jeton, par exemple en écoutant sur un réseau public, et que vous effectuez un rafraîchissement de jeton à ce moment-là, vous pourriez réutiliser ce refresh token volé. C'était tout à fait possible dans mes précédentes entreprises. 

Forts de cette expérience, nous avons choisi de rendre cela impossible en utilisant des clés privées sur l'appareil de l'utilisateur, ce qui nous permet de détecter si un refresh token est réutilisé par un autre appareil, grâce à une solution que nous appelons DPoP. C'est une sécurité supplémentaire, et nous disposons également d'un historique d'empreintes numériques (fingerprinting) qui nous aide à identifier s'il s'agit d'un appareil différent réutilisant la même session.

C'est un problème concret car, lorsque vous développez en interne, vous vous focalisez principalement sur la connexion et vous oubliez ce qui se passe après ; les utilisateurs rafraîchissent une session bien plus souvent qu'ils ne se connectent réellement. 

Ce processus gagne en sécurité précisément parce qu'il partage des signaux avec la partie fraude : côté front-end, nous collectons déjà de nombreuses informations à partir de l'appareil, ce qui facilite la détection de ces comportements.

Le compromis inévitable : Le risque de panne

Le seul véritable inconvénient, et je pense qu'il serait malhonnête de prétendre le contraire : la centralisation signifie qu'une panne peut paralyser les trois services en même temps, puisqu'ils se trouvent tous sur le même chemin critique.

Je ne vais pas prétendre que notre approche est une victoire absolue sur ce point, car ce n'est pas le cas. Si vous utilisez plutôt trois fournisseurs distincts, chacun d'eux reste son propre chemin critique pour la tâche qui lui incombe. Ainsi, la perte de l'un d'entre eux empêche toujours l'utilisateur de se connecter, ce qui revient exactement au même résultat que la panne de notre système intégré unique. 

La véritable différence réside dans le nombre de points de défaillance potentiels : une seule surface de panne qui entraîne tout le reste en même temps, contre trois surfaces distinctes, chacune capable de provoquer cette même défaillance à elle seule. C'est un choix qui se vaut, et je préfère le dire clairement plutôt que de le survendre pour ce qu'il n'est pas.

Là où les choses se compliquent : La migration

S'il existe un frein réel et légitime pour les clients potentiels, c'est bien la migration, et il est important d'expliquer précisément pourquoi.

Remplacer un fournisseur de vérification pure est presque un jeu d'enfant : il suffit de modifier un appel d'API, voire deux, et le tour est joué. 

L'authentification est un problème d'une tout autre dimension, car elle nécessite des données : qui est déjà inscrit, de quelle manière, y compris des éléments comme les connexions Google existantes qu'il faut transférer. Techniquement, cela reste une seule opération, mais c'est une action qui prend plusieurs semaines. De plus, comme elle ne s'apparente pas à une nouvelle fonctionnalité (comme le serait l'activation d'un nouveau moyen de paiement), elle n'est souvent pas jugée prioritaire par les équipes produit.

Tous les fournisseurs d'authentification se heurtent exactement à cette même difficulté, pas seulement Prelude.

L'aspect qui demande le plus d'attention est de ne pas perdre d'utilisateurs en cours de route. Il existe une réelle crainte, des deux côtés, qu'une erreur de migration déconnecte les utilisateurs, qu'un changement de mot de passe ou de numéro de téléphone bloque l'accès de quelqu'un à son propre compte, et ni les utilisateurs ni l'entreprise qui migre ne veulent de cela. C'est pourquoi la migration vers Prelude englobe également les sessions existantes, et pas seulement les identifiants de connexion, précisément pour que les personnes déjà connectées le restent tout au long de la transition.

La simplicité comme véritable facteur de différenciation

Ce qui nous distingue réellement des concurrents qui ont eux aussi commencé à parler de l'unification de ces briques se résume à deux choses : avoir une réelle longueur d'avance sur la partie fraude (plus particulièrement sur la vérification par SMS), et un parti pris délibéré sur le niveau de contrôle que la plateforme retire au client.  

La plupart des fournisseurs de connexion vous imposent une page de redirection, ce qui s'avère particulièrement inconfortable sur mobile : une page web qui s'ouvre à l'intérieur d'une application mobile donne rarement l'impression d'une expérience native. 

Prelude Auth a pris le parti de ne pas concevoir cette interface utilisateur : nous gérons la sécurité et la logique backend, nous exposons la connexion sous la forme d'une méthode que le client appelle directement, et nous le laissons concevoir sa propre interface par-dessus. C'est un véritable arbitrage par rapport à un concurrent proposant une solution clé en main basée sur des pages prêtes à l'emploi, et c'est un choix délibéré.

Cette même philosophie se retrouve dans notre tarification et notre périmètre d'action. L'objectif affiché est de ne pas facturer à la fonctionnalité, afin qu'une nouvelle capacité n'augmente pas discrètement la facture du client, contrairement aux fournisseurs qui intègrent d'office des fonctionnalités que personne n'a demandées. 

Notre vision est de concevoir les fonctionnalités dont 90 % des utilisateurs ont besoin, même si cela implique de passer à côté de 10 % de clients potentiels. Le plus important n'est pas le nombre de méthodes de connexion que vous proposez : il existe suffisamment de standards documentés, et une grande partie de cette documentation peut alimenter une IA pour la concevoir à votre place.

Le point névralgique de l'authentification reste la fraude. C'est sur ce terrain que nous pouvons nous montrer extrêmement performants.

Deux cas concrets de fraude que cette approche permet de bloquer

Deux exemples précis méritent d'être cités directement, car ils sont suffisamment concrets pour être vérifiés plutôt que simplement affirmés.

Les attaques par dictionnaire basées sur des fuites de données. Une part non négligeable des attaques par force brute sur les identifiants ne sont pas le fruit du hasard. Elles s'appuient sur des informations qui ont déjà été divulguées : une adresse, le nom d'un proche, le prénom d'un enfant. Un attaquant peut ainsi dresser une liste restreinte de mots de passe probables et procéder à quelques tentatives espacées dans le temps, tout en restant constamment sous les seuils classiques de limitation du débit. Par exemple, quelques tentatives toutes les dix minutes pendant quelques jours, plutôt qu'une rafale qui déclencherait une alerte évidente. J'ai été confronté à ce cas de figure par le passé, avant même d'arriver chez Prelude ; c'est précisément pour détecter cela que la solution Watch a été conçue, en s'appuyant sur des signaux partagés plutôt que sur un simple comptage brut des tentatives.

Les proxys résidentiels à grande échelle. Les bots cherchent à se dissimuler, et l'une de leurs méthodes consiste à alterner entre des adresses IP résidentielles plutôt que d'utiliser des adresses manifestement suspectes. Une analyse réseau permet d'identifier ce comportement, mais uniquement si elle porte sur un volume suffisant : une seule tentative de connexion lente et prudente toutes les vingt minutes ne présente rien d'anormal en soi. C'est la récurrence du schéma à grande échelle, couplée à ce qui se produit ensuite sur le site, qui finit par trahir l'attaque. Un système qui n'analyse que l'authentification de manière isolée passera totalement à côté.

Ce à quoi cela se résume concrètement

Notre pari est que le partage de signaux entre la vérification, l'authentification et la protection contre la fraude, conçus comme un ensemble unifié plutôt que comme trois achats distincts raccordés entre eux, constitue une solution structurellement différente et bien plus puissante que les trois mêmes briques développées séparément puis connectées après coup.

Ce que je retiens de mon travail sur ce projet, après avoir développé l'authentification en interne pour une seule entreprise au début de ma carrière, par rapport au développement de celle-ci en tant que plateforme partagée pour un grand nombre de clients : ce sont deux disciplines fondamentalement différentes. 

L'accès aux données de nombreux clients, plutôt qu'à la seule fraction de données d'un unique produit, constitue la véritable clé. Un schéma d'attaque mondial apparaît sur l'ensemble de la base de clients d'une plateforme partagée bien avant de toucher l'un d'entre eux individuellement. 

Lorsque vous développez en interne, vous ne voyez jamais que votre propre périmètre, et c'est exactement le manque de visibilité que je décrivais au début de cet article du point de vue opposé, des années plus tôt, sans encore pouvoir le nommer.

Vous souhaitez voir comment cela s'intègre à votre stack ?

Si tout cela, et en particulier le détail sur les refresh tokens, fait écho à un problème que vous résolvez actuellement à l'aide de trois fournisseurs distincts, venez échanger avec l'équipe Auth au sujet de votre architecture spécifique.

Loïc Madiès est ingénieur chez Prelude, où il travaille sur la partie Auth. Il a rejoint l'équipe après avoir travaillé chez Leboncoin sur la gestion des sessions et les systèmes de lutte contre la fraude, apportant cette expertise directement dans la manière dont le produit Auth de Prelude partage aujourd'hui les signaux entre les sessions. Il a étudié l'ingénierie à Polytech Lyon.