Validation en 2 étapes (Two Factor Authentication, 2FA)

Toutes les versions de cet article : [English] [français]

Un règlement de l’UE ( en vigueur depuis septembre 2019 ) exige une authentification de paiement à deux facteurs, appelée « Authentification client forte » (SCA).

Le besoin de la validation à 2 étapes se fait également sentir pour la connexion des utilisateurs aux applications sensibles. Le principe de la validation à 2 étapes (Two Factor Authentication, 2FA) est bien connu depuis plusieurs années et mis en oeuvre de différentes manières, la plus courante étant le code envoyé par SMS.

OAuthSD implémente l’authentification à deux facteurs par SMS ou avec Google Authenticator.

Qu’est-ce que 2FA ?

La sécurité apportée par un simple mot de passe n’est pas toujours suffisante.

L’authentification à deux facteurs, également connue sous le nom de 2FA, vérification en deux étapes ou TFA, est une couche de sécurité supplémentaire appelée « authentification à plusieurs facteurs », qui requiert non seulement un mot de passe et un nom d’utilisateur, mais aussi quelque chose que cet utilisateur possède, qui est avec lui et que personne d’autre ne possède ou ne connait.

Après le login, donnez une deuxième preuve de votre identité

Le processus commence comme d’habitude, l’utilisateur final donnant son identifiant et son mot de passe :

Il lui est demandé de fournir une deuxième preuve d’identité : OAuthSD propose la méthode classique par SMS ou l’identification avec Google Authenticator.

2FA par SMS

Si cette première étape se termine avec succès, OAuthSD enchaîne sur une demande de code par SMS :

Le SMS est envoyé au numéro de smartphone enregistré avec le profil de l’utilisateur [1].

Après confirmation, le consentement est demandé si nécessaire, comme d’habitude :

2FA avec Google Authenticator

Google Authenticator est un système de 2FA qui génère un TOTP.

Qu’est-ce que TOTP ?

TOTP est une forme abrégée de "Time-based One-time Password " ou "mot de passe à utilisation unique à durée déterminée". Il s’agit d’un mot de passe qui ne peut être utilisé qu’une seule fois et qui ne peut être utilisé que dans une plage de temps définie. Généralement, les générateurs TOTP génèrent de nouveaux mots de passe toutes les quelques dizaines de secondes tel que défini.

Après le login, donnez une deuxième preuve de votre identité avec Google Authenticator

Le processus commence comme d’habitude, l’utilisateur final donnant son identifiant et son mot de passe comme précédemment.

Il lui est demandé de fournir une deuxième preuve d’identité : Google Authenticator qu’il ou elle a installé sur son smartphone lui donnera le code nécessaire.

Cela nécessite d’enregistrer OAuthSD sur Google Authenticator en tant qu’application [2]. C’est pour cela que le QRCode est utilisé. Voir de nombreux tutoriels sur le Web. C’est une action unique pour la vie du smartphone : une fois que c’est fait, GA affichera un code toutes les 30 secondes : rien à retenir !

Après confirmation, le consentement est demandé si nécessaire, comme d’habitude.

Pourquoi Google Authenticator ?

Qu’en est-il du suivi (tracking) ? Les applications délèguent l’identification de l’utilisateur à OAuthSD. Cela signifie que Google voit le serveur OAuthSD et non les applications. Google sait qu’un utilisateur est lié à OAuthSD, mais ne voit pas la relation avec l’application : il n’y a donc pas de suivi de l’activité de l’internaute sur l’application (tracking) ... à condition qu’il n’y ait pas de fuite de suivi ailleurs dans cette application !

TFA avec NoPassConnect

Nous développons NoPassConnect (précédemment SmartConnect), une application de mobile sans mot de passe (passwordless) qui peut être utilisée comme première méthode d’authentification aussi bien qu’en deuxième.

Avec l’application NoPassConnect installée sur votre mobile, il vous suffit de scanner le QR-Code présenté par l’application pour ouvrir votre session OpenID Connect :

Configurer TFA sur OAuthSD

Une demande de deuxième validation est présentée à l’utilisateur final :
Si la constante de configuration LOGIN_WITH_TFA est définie sur true, le formulaire 2FA sera toujours présenté à l’utilisateur final après le formulaire de connexion.
sinon, le scope réservé "tfa" doit être présent dans la demande d’autorisation ; l’application devra donc avoir été enregistrée sur le serveur avec le scope ’tfa’.
la constante de configuration TFA_PROVIDER permet de définir le deuxième mode d’identification (’gangsta’, ’checkbysms’, ’smartconnect’ ...).

Et ensuite ?

Dans l’état actuel du développement, il existe trois méthodes disponibles pour 2FA : TFA par SMS (la solution classique !), Google Authenticator et DnC NoPassConnect.

D’autres fournisseurs d’identités suivront bientôt, y compris le nôtre (= votre serveur privé) pour une sécurité de niveau supérieur.

Nous pouvons développer tout système privé adapté aux besoins particuliers de nos clients, comme nous l’avons fait avec l"’Identification OpenID Connect avec ID Card : Aramis .