Pourquoi vous devriez utiliser l'authentification tierce (OAuth) pour votre application Web
OAuth élimine le besoin de stocker des mots de passe utilisateur confidentiels sur votre serveur. Au lieu de cela, l'utilisateur vous fait confiance pour accéder à ses informations de profil de base à partir d'un service comme Google, qui gère l'authentification pour vous.
Sommaire
L'authentification tierce vous évite de gérer les mots de passe
La connexion par un tiers est une alternative à l'authentification par nom d'utilisateur / mot de passe. Vous avez certainement déjà rencontré ce problème si vous avez déjà été invité à vous connecter avec Google ou Facebook: il vous suffit de vous authentifier avec votre profil de réseau social sans entrer de mot de passe.
Il est plus facile de parler des problèmes liés aux alternatives. Si vous ne souhaitez pas utiliser l'authentification tierce, vous devrez tout gérer vous-même. Cela signifie que vous serez responsable du stockage des mots de passe de vos utilisateurs, ce qui n’est pas impossible s’ils sont correctement salés et hachés. Mais c'est un problème, et vous ne voulez pas être responsable d'une éventuelle violation de données impliquant des mots de passe, même s'ils sont correctement stockés.
La connexion par un tiers élimine le risque que cela se produise, car vous ne gérerez jamais rien de privé. Ce travail est laissé à Google, Facebook et tout autre fournisseur OAuth. Même si l'ensemble de votre réseau de serveurs est compromis, vous n'aurez accès à rien, à l'exception des profils de réseaux sociaux accessibles au public.
Quel est l’inconvénient?
Théoriquement, il n'y a rien de différent sur OAuth par rapport à l'authentification par mot de passe; il s'agit simplement d'une manière différente de se connecter. Mais dans la pratique, OAuth soulève quelques problèmes.
Tout d'abord, vous devez faire confiance au fournisseur OAuth pour gérer en toute sécurité les données de votre utilisateur. Ce n’est pas vraiment votre problème, car toute violation de leur part n’affecte pas votre service. Mais le contrôle sur la connexion des utilisateurs est transféré au fournisseur, ce que certaines personnes peuvent ne pas accepter.
L'utilisateur doit également vous faire confiance pour s'authentifier auprès du fournisseur, et il doit également avoir un compte auprès de l'un des fournisseurs. La solution à cela est d'offrir plusieurs fournisseurs; un utilisateur peut ne pas vouloir s'inscrire avec son compte Facebook, mais il se peut qu'il puisse s'inscrire avec son compte Gmail.
Cependant, cela présente un autre problème propre à OAuth: les utilisateurs peuvent créer plusieurs comptes par accident. Souvent, le processus d'inscription est le même que celui de la connexion, car il est géré dans le même flux. Cela peut amener les utilisateurs à oublier le compte avec lequel ils se sont inscrits et à s'inscrire accidentellement avec un nouveau compte. Cela pourrait même constituer une violation du GDRP s’il n’est pas géré correctement. Vous voudrez vous assurer que «Inscription» et «Connexion» sont gérées séparément.
Comment ça marche?
La connexion tierce utilise OAuth 2.0 pour l'authentification. OAuth est un ensemble de normes et il existe de nombreux flux OAuth différents pour différents cas d'utilisation. Le plus couramment utilisé pour la connexion sociale est le flux de code d'autorisation.
Dans le flux de code d'authentification, votre serveur fournit votre application Web comme d'habitude au client. Lorsqu'ils cliquent sur "S'inscrire", ils sont redirigés vers votre page de connexion avec le fournisseur OAuth (Google, dans cet exemple). Vous devrez enregistrer votre application auprès de Google et fournir certaines informations que vos utilisateurs verront. Google demandera à l'utilisateur s'il est d'accord si votre application accède aux informations de son profil.
Si l'utilisateur accepte, Google les redirige vers une URL de rappel avec un code d'autorisation.
Ce code d'autorisation fonctionne comme la clé du compte de l'utilisateur. Bien que ce ne soit pas exactement une clé; cela ressemble plus à une IOU où le client confirme que le serveur est autorisé à accéder au compte. Il ne peut être utilisé que par votre serveur.
Il n'est utilisé qu'une seule fois, car votre serveur transmettra immédiatement la clé à Google pour obtenir un jeton d'accès et un jeton d'identification, qui sont utilisés pour accéder réellement au compte de l'utilisateur. Vous pouvez éventuellement demander un jeton d'actualisation pour mettre à jour le jeton d'accès après son expiration, sans demander à l'utilisateur un autre code d'autorisation.
Dans ce flux, vous ne demandez l'accès que pour afficher les informations de profil de base, afin de pouvoir identifier l'utilisateur. Cela s'appelle votre portée, qui correspond à la quantité de données et au nombre de fonctions auxquelles vous êtes autorisé à accéder. Chaque fournisseur OAuth a des champs d'application différents (voici une liste de Google), et vous pouvez également utiliser OAuth pour l'accès administratif aux comptes, tels que les services qui auraient besoin d'accéder à la boîte de réception d'un utilisateur ou au compte Google Drive.
Comment le configurer?
Nous utiliserons les bibliothèques OAuth de Google pour cet exemple, car elles sont simples à configurer. Mais Facebook, Github et Twitter Tous sont également des fournisseurs OAuth populaires, et il est judicieux d’implémenter au moins deux fournisseurs dans votre application. Et si vous développez une application iOS, vous devez implémenter Apple en tant que fournisseur OAuth via son programme Se connecter avec Apple (si vous utilisez la connexion par un tiers en premier lieu).
Tout d'abord, accédez à la console API Google et créez un nouveau projet. Sélectionnez «Navigateur Web» comme type de client et spécifiez votre URL d'origine.
Ensuite, incluez la bibliothèque de la plateforme Google en tant que script sur votre site:
Et incluez votre identifiant client en tant que balise Meta dans l'en-tête de votre site:
Vous pouvez implémenter le bouton vous-même ou utiliser le bouton prédéfini:
À partir de là, les utilisateurs devraient pouvoir s'authentifier complètement. Mais ce bouton définit un rappel, «onSignIn», dans lequel vous souhaiterez effectuer tout le traitement dont vous avez besoin. Par exemple, vous pouvez demander à Google des informations de profil de base sur l'utilisateur:
function onSignIn(googleUser) { var profile = googleUser.getBasicProfile(); console.log('ID: ' + profile.getId()); // Do not send to your backend! Use an ID token instead. console.log('Name: ' + profile.getName()); console.log('Image URL: ' + profile.getImageUrl()); console.log('Email: ' + profile.getEmail()); // This is null if the 'email' scope is not present. }
Si vous vous authentifiez davantage avec un serveur backend, vous souhaiterez envoyer des jetons d'identification plutôt que des informations de profil, car ceux-ci peuvent être validés par le serveur.
Si vous ne souhaitez pas le configurer vous-même, vous pouvez utiliser Auth0, qui est gratuit pour jusqu'à 7 000 utilisateurs mensuels, et prend également en charge Touch ID et l'authentification à deux facteurs. Ou vous pouvez utiliser une autre bibliothèque comme react-google-login, qui gérera ce processus dans une application React.