Accueil > OpenID Connect OAuth Server par DnC > Développer > Validation en 2 étapes (Two Factor Authentication, 2FA)

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

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

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 ?

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 a sur lui, c’est-à-dire un élément d’information qu’il devrait connaître ou avoir immédiatement sous la main - comme un jeton physique.

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 ... à condition qu’il n’y ait pas de fuite de suivi ailleurs dans cette application !

Et ensuite ?

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.

2FA pour les développeurs

Il existe des informations complémentaires, connectez vous pour les voir.

Notes

[1La méthode d’identification par SMS échouera donc si aucun numéro n’a été enregistré pour l’utilisateur qui tente de s’identifier.

[2Notons que c’est bien OAuthSD qui est enregistré sur Google Authenticator, et non les applications clientes. On conserve donc tout l’avantage de la délégation d’authentification pour interdire le tracking de la navigation des utilisateurs finaux.