Ce que vous devez savoir sur OAuth2 et la connexion avec Facebook

Au cas où vous vous demanderiez ce qu'est OAuth2, c'est le protocole qui permet à n'importe qui de se connecter avec son compte Facebook. Il alimente le bouton "Se connecter avec Facebook" dans les applications et sur les sites Web partout.

Cet article vous montre comment fonctionne "Connexion avec Facebook" et explique le protocole derrière tout cela. Vous apprendrez pourquoi vous voudriez vous connecter avec Facebook, Google, Microsoft ou l'une des nombreuses autres sociétés qui prennent en charge OAuth2.

Cet article vous montre comment fonctionne "Connexion avec Facebook" et explique le protocole derrière tout cela. Vous apprendrez pourquoi vous voudriez vous connecter avec Facebook, Google, Microsoft ou l'une des nombreuses autres sociétés qui prennent en charge OAuth2.

Nous allons examiner deux exemples : pourquoi Spotify utilise Facebook pour vous permettre de vous connecter à l'application mobile Spotify, et pourquoi Quora utilise Google et Facebook pour vous permettre de vous connecter à son site Web.

Lectures complémentaires sur SmashingMag :

• Quatre façons de créer une application mobile
• Comment créer des interfaces utilisateur honnêtes et aider les utilisateurs à prendre de meilleures décisions
• Garder votre application Android populaire après son lancement
• Listes de lecture Spotify pour alimenter vos sessions de codage et de conception
  

Avant OAuth2

OAuth2 a remporté une bataille de standards il y a quelques années. C'est le seul protocole d'authentification pris en charge par les principaux fournisseurs. Google recommande OAuth2 pour toutes ses API, et l'API Graph de Facebook ne prend en charge que OAuth2.

La meilleure façon de comprendre OAuth2 est de regarder ce qui l'a précédé et pourquoi nous avions besoin de quelque chose de différent. Tout a commencé avec Basic Auth.

Authentification de base

Les schémas d'authentification se concentrent sur deux questions clés : qui êtes-vous ? Et pouvez-vous le prouver?

La façon la plus courante de poser ces deux questions est d'utiliser un nom d'utilisateur et un mot de passe. Le nom d'utilisateur indique qui vous êtes et le mot de passe le prouve.

Basic Auth a été le premier schéma d'authentification Web. Cela semble drôle, mais "authentification de base" était son nom réel dans la spécification publiée pour la première fois en 1999.

L'authentification de base permet aux serveurs Web de demander ces informations d'identification d'une manière compréhensible pour les navigateurs. Le serveur renvoie un code de réponse HTTP de 401 (ce qui signifie qu'une authentification est requise) et ajoute un en-tête spécial à la réponse, nommé WWW-Authenticate , avec une valeur spéciale de Basic .

Lorsque le navigateur voit ce code de réponse et cet en-tête, il affiche une boîte de dialogue de connexion contextuelle :

La grande partie de Basic Auth est sa simplicité. Vous n'avez pas besoin d'écrire un écran de connexion. Le navigateur gère tout cela et envoie simplement le nom d'utilisateur et le mot de passe au serveur. Cela donne également au navigateur la possibilité de gérer spécialement le mot de passe, que ce soit en le mémorisant pour l'utilisateur, en l'obtenant à partir d'un plugin tiers ou en prenant les informations d'identification de l'utilisateur à partir de son système d'exploitation.

L'inconvénient est que vous n'avez aucun contrôle sur l'apparence de l'écran de connexion. Cela signifie que vous ne pouvez pas le styliser ou ajouter de nouvelles fonctionnalités, telles que "Mot de passe oublié?" lien ou une option pour créer un nouveau compte. Si vous voulez plus de personnalisation, vous devrez écrire un formulaire de connexion personnalisé.

Formulaires de connexion personnalisés

Les formulaires de connexion personnalisés vous donnent tout le contrôle que vous pourriez souhaiter. Vous écrivez un formulaire HTML et demandez les informations d'identification. Vous soumettez ensuite le formulaire et gérez la connexion comme vous le souhaitez. Vous obtenez un contrôle total : vous pouvez le styliser, demander plus de détails ou ajouter plus de liens.

Certains sites Web, tels que WordPress, utilisent un formulaire simple pour l'écran de connexion :

LinkedIn permet aux utilisateurs de se connecter ou de créer un compte sur la même page, sans avoir à se rendre sur une autre partie du site :

La connexion par formulaire est très populaire, mais elle pose un problème fondamental majeur : les utilisateurs doivent indiquer leur mot de passe au site Web.

Garder les secrets secrets

Dans les cercles de sécurité, nous appelons un mot de passe un secret. C'est une information que vous seul avez et qui prouve que vous êtes vous. Le secret peut également être plus qu'un simple mot de passe ; nous en reparlerons un peu plus tard.

Un site Web peut prendre toutes les mesures de sécurité du monde, mais si l'utilisateur partage son mot de passe, cette sécurité disparaît. Les pirates ont piraté le site Web de Gawker en 2010, exposant les mots de passe de nombreux utilisateurs. Bien que ce soit un problème pour Gawker, le problème ne s'est pas arrêté là. La plupart des gens réutilisent les mots de passe, alors les pirates ont pris les données divulguées de Gawker et ont essayé de se connecter à des sites Web plus critiques, tels que Gmail, Facebook et eBay. Quiconque a utilisé un mot de passe Gawker pour des choses plus importantes a perdu beaucoup plus que les derniers potins sur la sex tape de Hulk Hogan.

S'assurer que vos utilisateurs ne réutilisent pas un mot de passe pour plusieurs comptes est la première moitié du problème - et c'est impossible. Tant que les gens devront créer des comptes différents partout sur Internet, ils réutiliseront leurs mots de passe.

La seconde moitié du problème consiste à stocker les mots de passe en toute sécurité.

Lorsque quelqu'un se connecte à votre application, vous devez vérifier son mot de passe, ce qui signifie que vous avez besoin d'une copie pour le vérifier. Vous pourriez stocker tous les noms d'utilisateur et mots de passe dans une base de données quelque part, mais maintenant vous risquez de perdre ces mots de passe ou d'être piraté. La meilleure pratique consiste à utiliser une fonction de hachage, telle que l'une des fonctions SHA-2. Cette fonction crypte les données de manière à ce que vous ne puissiez jamais les récupérer, mais vous pouvez répliquer le cryptage : "mon mot de passe" hachera quelque chose comme bb14292d91c6d0920a5536bb41f3a50f66351b7b9d94c804dfce8a96ca1051f2 à chaque fois.

Et voilà, c'est parti dans les hautes herbes : je vous explique comment implémenter des protocoles cryptographiques. Ensuite, je vais devoir vous expliquer comment ajouter du sel à vos données et quels manuels lire sur les attaques de l'homme du milieu. Tout ce que vous vouliez faire, c'est écrire une application, et maintenant vous devez devenir un expert en sécurité. Nous devons prendre du recul.

OAuth2

Vous n'êtes probablement pas un expert en sécurité. Même si vous l'êtes, je ne vous ferais toujours pas confiance avec mon mot de passe. OAuth2 vous offre un meilleur moyen.

Par exemple, j'utilise Spotify sur mon iPad. Je paie 10 $ par mois à l'entreprise pour écouter de la musique. Spotify ne me donne accès qu'à trois appareils, j'ai donc besoin d'un mot de passe pour m'assurer que personne d'autre n'utilise mon compte. Mon compte Spotify n'est pas un gros problème de sécurité. Se faire pirater ne serait pas la fin du monde, mais l'entreprise a ma carte de crédit, donc je veux m'assurer que je suis en sécurité.

Je ne me connecte presque jamais à Spotify, donc je ne veux pas créer un autre compte et devoir me souvenir d'un autre mot de passe. Spotify me donne une meilleure option :

Je peux utiliser mon compte Facebook pour me connecter. Lorsque j'appuie sur ce bouton, Spotify m'envoie sur facebook.com et je m'y connecte. Cela peut sembler être un petit détail, mais c'est l'étape la plus importante de tout le processus.

Les programmeurs de Spotify auraient pu rédiger eux-mêmes un formulaire de connexion, puis envoyer mon nom d'utilisateur et mon mot de passe à Facebook avec une API back-end, mais il y a deux grandes raisons pour lesquelles je ne veux pas qu'ils le fassent :

• Je ne fais pas confiance à Spotify avec mon mot de passe Facebook. J'utilise Facebook pour me connecter avec des amis et je ne veux pas me faire pirater. Je ne crois pas que Spotify gérera correctement le mot de passe. Je ne crois pas non plus que cela évitera la tentation de faire quelque chose de drôle avec. Peut-être qu'il essaierait de le stocker pour pouvoir l'utiliser plus tard. Peut-être qu'il y a un bogue qui l'écrit dans un fichier quelque part avant de l'envoyer à Facebook, afin qu'un pirate puisse le récupérer. Je suis désolé, Spotify ; Je ne suis pas du genre à faire confiance.
• Je ne veux pas laisser Spotify tout faire. Je veux que Spotify diffuse de la musique. Je ne veux pas qu'il soit posté sur les murs de mes amis quand j'écoute les Spice Girls. Je ne veux pas non plus le laisser télécharger ma liste d'amis et les inviter à rejoindre Spotify. Si je donnais à Spotify mon mot de passe Facebook, il pourrait alors se connecter en tant que moi sur Facebook ; il pourrait faire tout ce que je pouvais faire.

Il y a aussi deux grandes raisons pour lesquelles Spotify ne veut pas faire ça :

• Facebook me propose plusieurs options pour me connecter. . Je peux soit me connecter avec mon nom d'utilisateur et mon mot de passe, soit me connecter avec l'application Facebook. Je peux également récupérer mon mot de passe sur Facebook ou obtenir de l'aide que Spotify ne peut pas me donner. Si je donnais juste mon mot de passe à Spotify, je n'aurais aucune de ces options.
• Mon secret n'est peut-être pas un mot de passe. . Un mot de passe est une sécurité suffisante pour mon compte Spotify à 10 $ par mois, mais ce n'est peut-être pas suffisant pour ma banque ou quelque chose d'encore plus important. Il y a beaucoup d'autres secrets que je pourrais fournir : je pourrais avoir une carte à puce, ou je pourrais vivre dans un film Mission Impossible et utiliser un scanner rétinien.

Je ne suis pas dans un film Mission Impossible, mais dans le monde réel, de nombreuses entreprises utilisent une authentification à deux facteurs, comme un mot de passe plus autre chose. La méthode la plus courante consiste à utiliser votre téléphone. Lorsque vous souhaitez vous connecter, l'entreprise vous envoie un SMS avec un code spécial qui dure quelques minutes ; vous tapez ensuite le code ou utilisez une application pour le saisir.

Désormais, la société est sûre que personne ne peut se connecter à votre compte sans votre téléphone. Si quelqu'un vole votre mot de passe, il ne peut toujours pas se connecter. Tant que vous ne perdez pas votre téléphone, tout est sécurisé.

Facebook n'est pas le seul fournisseur OAuth2. Lorsque je me connecte à Quora avec mon compte Google, Google me dit ce que Quora aimerait faire et me demande si c'est d'accord :

Je pourrais accepter d'autoriser Quora à afficher mon adresse e-mail et les données de base de mon profil, mais je ne veux pas qu'il gère mes contacts. OAuth2 me montre tous les accès souhaités par Quora, ce qui me permet de choisir ce à quoi j'accorde l'accès.

Voilà donc les avantages d'OAuth2. Voyons voir comment ça fonctionne.

Comment fonctionne OAuth2

Facebook, Google et la plupart des autres fournisseurs OAuth2 traitent les clients natifs différemment des clients Web. Les clients natifs sont considérés comme plus sécurisés, et ils obtiennent des jetons et des jetons d'actualisation qui peuvent durer des mois. Les clients Web reçoivent des jetons beaucoup plus courts, qui expirent généralement lorsque l'utilisateur ferme le navigateur ou n'a pas cliqué sur le site Web pendant un certain temps.

Dans les deux cas, le processus de connexion est le même. La différence réside dans la fréquence à laquelle l'utilisateur doit le parcourir.

La connexion OAuth2 suit ces étapes générales :

1. L'utilisateur essaie de faire quelque chose qui nécessite une authentification. Cela peut être aussi simple que d'ouvrir une application ou de cliquer sur un bouton "Connexion".
2. L'application ou le site Web détermine que l'utilisateur ne s'est pas encore connecté et démarre le processus de connexion. Pour ce faire, il ouvre une page Web et l'envoie à une URL spéciale sur Facebook, Google ou tout autre site Web fournissant votre OAuth2.

L'ouverture d'une nouvelle fenêtre de navigateur pour le fournisseur OAuth2 est une étape cruciale. C'est ce qui permet aux fournisseurs d'afficher leurs propres formulaires de connexion et de demander à chaque utilisateur les informations de connexion dont il a besoin. La plupart des applications le font avec une vue Web intégrée.

En plus de l'URL de connexion du fournisseur, vous devez envoyer certains paramètres d'URL qui indiquent au fournisseur qui vous êtes et ce que vous voulez faire :

• client_id Cela indique au fournisseur OAuth2 quelle est votre application. Vous devrez enregistrer votre application à l'avance pour obtenir un ID client.
• redirect_uri Cela indique au fournisseur où vous voulez aller lorsque vous avez terminé. Pour un site Web, cela peut être un retour à la page principale ; une application native peut accéder à une page qui ferme la vue Web.
• response_type Cela indique au fournisseur ce que vous voulez en retour. Normalement, cette valeur est soit token , pour indiquer que vous souhaitez un jeton d'accès, soit code , pour indiquer que vous souhaitez un code d'accès. Les fournisseurs peuvent également étendre cette valeur pour fournir d'autres types de données.
• scope Cela indique au fournisseur à quoi votre application veut accéder. C'est ainsi que Google sait que Quora demande un accès pour gérer vos contacts. Chaque fournisseur a un ensemble différent de portées.

Il existe des champs supplémentaires qui peuvent ajouter plus de sécurité ou aider à la mise en cache. Certains fournisseurs peuvent également ajouter plus de champs, mais ces quatre sont les plus importants.

Une fois que votre application ouvre la vue Web, le fournisseur prend le relais. Ils peuvent simplement demander un simple nom d'utilisateur et un mot de passe, ou ils peuvent présenter plusieurs écrans demandant n'importe quoi, du nom de votre professeur préféré au nom de jeune fille de votre mère. C'est tout à eux. L'important est que, lorsque le fournisseur aura terminé, il vous redirigera vers vous et vous donnera un jeton.

Tout tourne autour des jetons

Une fois le processus terminé, le fournisseur vous donnera un jeton et un type de jeton. Il existe deux types de jetons : les jetons d'accès et les jetons d'actualisation. Le type de client que vous avez déterminera les types de jetons que vous êtes autorisé à demander.

Lorsque je me connecte à mon application Spotify, je peux rester connecté pendant des mois, car l'hypothèse est que mon téléphone n'est utilisé que par moi. Facebook fait confiance à l'application Spotify pour gérer les jetons, et je fais confiance à l'application Spotify pour ne pas perdre les jetons.

Lorsque le jeton d'accès expire (généralement en une à deux heures), Spotify peut utiliser le jeton d'actualisation pour en obtenir un nouveau.

Le jeton d'actualisation dure des mois. De cette façon, je n'ai à me connecter sur mon téléphone que quelques fois par an. L'inconvénient est que si je perds ce jeton d'actualisation, quelqu'un d'autre pourrait utiliser mon compte pendant des mois. Le jeton d'actualisation est si important qu'iOS fournit un trousseau pour les jetons, où il s'assure de les chiffrer et de les stocker en toute sécurité.

L'utilisation d'OAuth2 dans une application Web fonctionne de la même manière. Au lieu d'utiliser une vue Web, vous pouvez ouvrir la demande de connexion OAuth2 dans un cadre, un iframe ou une fenêtre séparée. Vous pouvez également l'ouvrir sur la page en cours, mais cela vous ferait perdre tout l'état de l'application JavaScript chaque fois que quelqu'un doit se connecter.

Lorsque je me connecte à Quora avec mon navigateur Web, je ne reçois pas de jeton d'actualisation. Ils veulent que le jeton expire et m'invitent à me reconnecter lorsque je quitte mon navigateur ou même que je pars pour le déjeuner. Les clients non approuvés ne peuvent pas actualiser le jeton car on ne peut pas leur faire confiance pour conserver le jeton d'actualisation important. C'est plus sécurisé mais moins pratique, car ils vous inviteront à vous reconnecter beaucoup plus fréquemment.

Utiliser OAuth2 dans votre application

Vous savez maintenant comment fonctionne OAuth2, mais vous ne souhaitez probablement pas implémenter votre propre client OAuth2. Vous pouvez aller lire l'intégralité de la spécification OAuth 2.0 de 75 pages si vous avez du mal à dormir, mais vous n'en avez pas besoin. Certaines bibliothèques intéressantes sont à votre disposition.

iOS a un support intégré pour OAuth2. Corrina Krych a un tutoriel très utile sur l'utilisation d'OAuth 2.0 avec Swift. Il vous explique comment obtenir un jeton, comment intégrer les vues dans votre application et où stocker vos jetons.

Android a également un support intégré pour OAuth2. Je dois admettre que je ne le connais pas aussi bien parce que je me concentre sur iOS, mais il y a de bonnes sections dans la documentation pour vous montrer des exemples et des bibliothèques open source pour le rendre encore plus facile.

JavaScript n'a pas de support intégré pour OAuth2, mais il existe des clients pour toutes les principales bibliothèques JavaScript. React prend entièrement en charge OAuth2. AngularJS a un support tiers pour OAuth2.0 pour de nombreux projets. J'en ai même écrit un.

Une fois que vous avez un client OAuth2, vous devrez choisir un fournisseur.

À qui faites-vous confiance ?

La grande hypothèse ici est que je fais plus confiance à Facebook qu'à Spotify. Je n'ai aucune bonne raison pour cela. Facebook ne rend pas sa sécurité interne publique, et je n'ai aucun moyen de la vérifier. Spotify non plus. Il n'y a pas de Consumer Reports pour la sécurité OAuth2. Je fais essentiellement confiance à Facebook parce que c'est plus gros. Je fais confiance à Facebook parce que d'autres le font.

Je fais également davantage confiance à Facebook chaque fois que je clique sur le bouton « Se connecter avec Facebook ». Si Facebook perd mon mot de passe, les pirates auront accès non seulement à mon compte Facebook, mais aussi à mon compte Spotify et à tout autre service auquel je me suis connecté avec mon compte Facebook. L'avantage est qu'il n'y a qu'un seul endroit où je dois réinitialiser mon mot de passe afin de résoudre le problème.

Je n'ai pas à faire confiance à Facebook, mais je dois faire confiance à quelqu'un. Quelqu'un doit m'authentifier. Je dois choisir le fournisseur en qui j'ai confiance.

Choisir un fournisseur OAuth2

Wikipedia maintient une liste de fournisseurs OAuth, mais vous ne vous souciez pas de la plupart d'entre eux. Les grands sont Facebook et Google. Vous pouvez également consulter Amazon ou Microsoft.

Tous les quatre sont grands et faciles à intégrer. Facebook fournit des instructions pour enregistrer une application. Google a des étapes similaires. L'idée de base est que vous créez un compte de développeur, puis créez un ID d'application. Le fournisseur vous donne ensuite un ID client que vous pouvez utiliser pour faire des demandes.

Vous pouvez également choisir plusieurs fournisseurs. Quora vous permet de vous connecter avec Facebook ou Google ; comme ils utilisent tous les deux OAuth2, vous pouvez utiliser le même code pour les deux.

Ce qui manque à OAuth2

OAuth2 fait un très bon travail pour résoudre un problème complexe, mais il manque quelques éléments :

• La norme n'est pas complètement standard. Je n'ai jamais été capable d'écrire un seul client OAuth2 capable de se connecter à la fois à Facebook et à Google sans quelques instructions if . Chacun interprète la spécification différemment, et il y a peu de détails différents pour chacun. Ils ont également toujours des idées différentes sur les étendues à fournir. L'utilisation d'une bibliothèque pour s'intégrer à OAuth2 aide beaucoup à résoudre ce problème, mais elle ne sera jamais transparente à 100 % dans le code de votre application.
• La déconnexion est délicate. . Chaque application ou site Web qui utilise OAuth2 a un bouton de déconnexion, mais la plupart oublieront simplement les jetons sans les invalider. L'application oubliera tous vos jetons actuels et permettra à quelqu'un d'autre de se connecter, mais vos jetons sont toujours valides. Si un pirate a volé votre jeton, il peut toujours l'utiliser et se connecter en votre nom.

Il existe une spécification distincte pour l'invalidation des jetons OAuth2, mais elle n'a pas été reprise par la plupart des principaux fournisseurs. OAuth2 ne fournit pas de moyen de récupération si un pirate obtient votre jeton d'actualisation ; même si vous pouvez supprimer votre copie locale du jeton, le pirate l'aura toujours. De nombreux fournisseurs vous permettent de suspendre votre compte, mais il n'y a pas de moyen standard de le faire.

Pour défendre OAuth2, il s'agit d'un problème difficile, car de nombreux fournisseurs utilisent la cryptographie à clé publique pour créer des jetons sans état. Cela signifie que le serveur ne se souvient pas des jetons qu'il a créés, il ne peut donc pas les oublier plus tard.

L'autre problème majeur avec OAuth2 est que vous dépendez de votre fournisseur. Lorsque Facebook tombe en panne, il en va de même pour le bouton "Se connecter avec Facebook" de votre application. Si Google décide de commencer à vous faire payer pour prendre en charge OAuth2 ou exige que vous partagiez vos bénéfices avec lui, vous ne pouvez rien faire. C'est l'épée à double tranchant de faire confiance à un fournisseur : il fait beaucoup pour vous, mais il contrôle vos utilisateurs.

OAuth2 dirige le monde

Même avec quelques fonctionnalités manquantes et une grande dépendance, OAuth2 reste un excellent choix. Cela permet aux utilisateurs de se connecter facilement à votre application, de ne pas avoir à se souvenir d'un mot de passe pour chaque site Web et de faire confiance à votre sécurité. OAuth2 est un choix très populaire. Il domine l'industrie. Aucun autre protocole de sécurité ne se rapproche de l'adoption d'OAuth2.

Vous savez maintenant d'où vient OAuth2 et comment il fonctionne. Allez faire des choix intelligents pour savoir à qui faire confiance, arrêtez de lire des articles sur le stockage en toute sécurité des mots de passe cryptés et passez plus de temps à écrire votre incroyable application.