3 façons d'implémenter les critères du PSD2 sur l'authentification forte des clients

May 13, 2021
Rédigé par

3 façons implémenter PSD2 authentification fort clients

La régulation européenne des Directives sur les Services de Paiement (PSD2) exige une Authentification Forte du Client (SCA) lorsqu’un client :

  • Initie un paiement électronique de plus de 30€*
  • Accède à son compte bancaire en ligne
  • Effectue n’importe quelle autre action à distance “qui puisse comporter un risque de fraude ou d’abus”.

Ceci s’applique à :

  • Les entreprises et/ou les clients au sein de l’Espace Economique Européen
  • Les transactions en ligne ou sans la présence de carte de débit ou de crédit.

Initialement, la date limite pour se conformer à cette nouvelle réglementation était en septembre 2019 mais elle a été rallongée jusqu’au 30 décembre 2020 (la date limite de la SCA au Royaume-Uni est maintenant fixée au 14 septembre 2021).

Il y a trois façons d’utiliser Twilio lors de la mise en place de la SCA pour les transactions dans votre application:

  1. Pour la vérification des mots de passe à usage unique (One-Time Passcodes = OTP)
  2. Pour l’authentification Push
  3. Pour les Time-based OTP Transactionnels (TOTP)

Cet article vous donnera un aperçu de chaque méthode et fournira les ressources nécessaires pour commencer.

*Les paiements exonérés incluent :

  • Des transactions à moindre risque (basées sur le taux de fraude de l’expéditeur)
  • Des paiements récurrents (“à l'initiative du vendeur” fixes ou variables)
  • Les paiements par téléphone

Les prérequis de la SCA pour les transactions “sans carte présente”

La SCA exige une authentification à double facteur (2FA) en utilisant une combinaison des critères suivants. Les éléments de sécurité conformes sont décrits en détail dans le document d’opinion June 2019 EBA (se référer aux tableaux 1,2 et 3).

  1. L’élément d’inhérence (“ce que l’utilisateur est”, par exemple : empreinte digitale, reconnaissance de voix, dynamiques de frappe…)
  2. L’élément de possession (“ce que l’utilisateur a”, par exemple : SMS OTP, les tokens matériels, les applications liées à l’appareil…)
  3. L’élément de connaissance (“ce que l’utilisateur sait”, par exemple : les mots de passe, codes PIN, et les schémas de déverrouillage enregistrés…)

Twilio peut aider avec le facteur de possession (“ce que l’utilisateur a”) en envoyant des mots de passe à usage unique par SMS; l’Authentification Push utilisant l’App Authy ou étant encodée dans votre propre application, ou bien en utilisant l’API Authy pour les transactions spécifiques TOPT. Ces méthodes supportent toutes l’édition de liens dynamiques. Les exigences attendues pour inclure les informations spécifiques de la transaction dans l’authentification comprennent :

  • Le bénéficiaire (particulier ou vendeur)
  • Le montant du paiement

Option 1 : L’API Twilio Verify SMS

Bien que les SMS soient une option pour la vérification, notez que les institutions financières dans certains pays, comme l’Allemagne, s’éloignent de cette méthode.

Assurez-vous que Transaction Verification est enabled sur votre Service de vérification dans la console.

vérification

Vous pouvez ensuite ajouter les informations de liens dynamiques sur la transaction lorsque que vous faites la requête API comme suit :

# Installez la CLI Twilio depuis https://twil.io/cli

twilio api:verify:v2:services:verifications:create \
   --service-sid VAXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX \
   --amount €39.99 \
   --payee "Acme Inc." \
   --to +15017122661 \
   --channel sms

Vous pouvez en apprendre plus sur l’utilisation de Verify for SCA dans la documentation.

Option 2 : Authentification Push

Le nouveau Verify Push SDK permet aux compagnies d’intégrer la logique d’Authentification Push directement dans leurs applications mobiles, créant un authentificateur compatible avec la SCA. Il utilise quelque chose que vos clients ont probablement déjà installé.

Vous pouvez en apprendre plus sur comment démarrer avec Verify Push dans la documentation. Comme l’API pour l’Authentification Push comprend déjà des champs de contexte additionnels, ajouter amount et payee marche déjà sans problèmes.

detail push

Option 3 : Time-based OneTime Passwords (TOTP) Transactionnels

L’algorithme TOTP est une manière standardisée de faire de l’authentification hors-ligne. C’est justement cette partie “hors-ligne” qui rend compliqué, pour la plupart des applications, le fait de remplir les exigences spécifiques de la transaction concernant les liens dynamiques. Mais Twilio a mis en œuvre une façon d’y arriver avec les TOTP Transactionnels.

Voici comment ça marche, en utilisant l’API et l’application Authy :

  • Ajoute un utilisateur à votre application Authy
  • Affiche un QR code secondaire à partir de la page de paiement - que l’utilisateur déjà inscrit pourra scanner à partir de l’App Authy

TOTP transactionnel

Comme c’est une solution propriétaire, elle ne fonctionnera donc pas avec les les autres applications d’authentification - comme TOTP le fait normalement. Mais c’est une bonne option pour le support d’authentification hors-ligne.

Allez voir ce post pour plus de détails sur comment vous lancer dans les TOTP.

Et ensuite ?

Si vous avez d’autres questions, contactez-nous - nous avons aidé beaucoup de compagnies à développer des solutions conformes et nous serions ravis de pouvoir vous aider également.

Vous cherchez des nouvelles façons d’ajouter une authentification forte à votre site ou application ? Nous avons plus d’idées et de tutoriels pour la l’authentification à double facteur (2FA) comme :