Je suis sûr que vous avez un ou plusieurs comptes de médias sociaux.
Que ce soit Facebook, Twitter, YouTube, Google, GitHub,
ou bien d'autres fournisseurs de services de ce type, où vous avez enregistré votre téléphone et votre compte.
Maintenant, ces fournisseurs de services à leur tour,
sont prêts à fournir des services d'authentification en votre nom.
Ainsi, par exemple, vous voyez la prolifération d'un certain nombre de sites Web
et d'applications mobiles où vous êtes autorisé à vous connecter à
l'aide de vos comptes de médias sociaux.
Maintenant, comment ça marche réellement ?
Beaucoup de ces fournisseurs de comptes de médias sociaux agissent
en tant que fournisseurs de services d'authentification utilisant un protocole appelé OAuth.
Nous allons examiner OAuth et comment il permet à ces fournisseurs d'authentification tiers de
fournir une authentification en votre nom
et vous permettre de vous connecter à d'autres services à l'aide de leurs comptes de médias sociaux.
Je suis sûr que vous avez peut-être entendu parler de OAuth 1 et OAuth 2,
et peut-être entendu des gens dire
que Facebook fournit l'authentification basée sur OAuth 2,
ou Google fournit l'authentification basée sur OAuth 2 et ainsi de suite.
Je suis sûr que vous devez vous demander,
ce que ces OAuth1 et OAuth 2 sont censés être exactement ?
Maintenant, OAuth1 et OAuth 2 sont des frameworks
d'autorisation basés sur des standards ouverts.
Et ceux-ci peuvent être utilisés sur Internet pour authentifier
votre identité sur de nombreux sites Web ou applications mobiles.
Maintenant, lorsque vous utilisez ces services,
vous dépendrez de l'un des comptes de médias sociaux comme Facebook,
Google, Twitter, Microsoft, Instagram,
GitHub, DigitalOcean, et bien d'autres,
qui fournissent ces services d'authentification à d'autres utilisateurs.
Ces fournisseurs de services d'authentification promettent
aux utilisateurs de ces services d'authentification qu'ils authentifieront l'identité
de l'utilisateur en fonction de leur soumission de
leurs informations d'identification pour ces services de médias sociaux.
Maintenant, il existe un service complémentaire OpenID.
Mais, bien sûr, pas lié à OAuth mais fournit un type de service similaire.
Mais la plupart des fournisseurs de services de médias sociaux standard,
comme vous le verrez ci-dessous,
fournissent des services basés sur OAuth 2 ces jours-ci.
Maintenant, comme je l'ai mentionné, OAuth1 et OAuth 2 sont des protocoles d'authentification,
et OAuth 1 a été le premier protocole à être né.
Cela a été développé à partir de Twitter,
Blaine Cook étant la personne derrière elle,
et cela est documenté dans Internet Engineering Task Force, RFC 5849.
Donc, si vous voulez lire les détails gorieux de la façon dont ces protocoles fonctionnent,
c'est l'endroit pour le trouver. Le
protocole OAuth 2 a évolué à partir d'OAuth 1 pour le rendre plus simple
et pour fournir un moyen plus simple de développement client.
Et cela est documenté dans IETF RFC 6749 et par la suite,
une autre utilisation de jeton de porteur est apparue dans IETF RFC 6750.
Maintenant, de notre point de vue,
nous ne voulons pas vraiment entrer dans les détails de la façon dont ces protocoles fonctionnent réellement.
Au lieu de cela, tout ce qui nous intéresse, c'est,
comment les utiliser pour l'authentification des utilisateurs dans notre application Web,
ou dans notre application mobile,
quand nous devons authentifier l'utilisateur sur
le serveur Express sur lequel nous avons construit jusqu'à présent ?
Maintenant, nous allons principalement nous concentrer sur OAuth 2,
parce que dans l'exercice,
nous allons examiner l'utilisation de Facebook en tant que fournisseur de services d'authentification OAuth 2
, et ici, nous devons comprendre
quelques termes pour voir comment fonctionne exactement ce protocole OAuth 2.
Au moins, les détails nus de la façon dont le protocole lui-même fonctionne.
Maintenant, dans le cas d'OAuth 2,
nous parlons toujours d'une propriété de ressource.
Maintenant, dans ce cas,
la ressource à laquelle je fais référence n'est pas
la ressource qui est stockée sur le serveur Express.
Au lieu de cela, la ressource à laquelle nous faisons référence ici,
est l'identité de l'utilisateur.
Maintenant, tout serveur, comme le serveur Express que nous avons construit,
veut avoir accès à cette ressource,
c'est votre identité.
Où est votre identité ?
Votre identité est stockée sur l'un de
ces fournisseurs de services d'authentification de médias sociaux comme Facebook et ainsi de suite,
car vous avez déjà créé un compte sur ces sites de médias sociaux.
Ainsi, vos informations, vos informations d'identité ou
vos informations de profil sont stockées sur Facebook, par exemple.
Maintenant, votre serveur Express veut accéder à votre identité et
vérifier que c'est vraiment vous qui essayez d'accéder au serveur Express.
Ainsi, dans ce cas,
le serveur Express que nous avons développé,
agit comme l'application cliente.
Donc, c'est là que l'application cliente,
qui est le site Web ou l'application mobile qui
veut accéder au serveur de ressources afin d'obtenir les informations vous concernant.
Qu' est-ce qu'un serveur de ressources dont nous parlons ?
Il s'agit du serveur d'authentification OAuth Facebook,
qui fournit également vos informations de profil sur demande.
Maintenant, bien sûr, vous ne continuerez pas de distribuer au hasard les informations de votre profil.
Au lieu de cela, vous souhaitez être en mesure de vérifier que vous fournissez l'accès aux
informations de votre profil à un fournisseur de services authentifié ou à un serveur authentifié.
Maintenant, c'est là que votre application cliente ou le serveur Express ici,
par exemple, s'inscrira sur Facebook avec un compte disant que j'exploite une application,
et je veux m'inscrire en tant que source potentielle qui peut
vous approcher pour authentifier les utilisateurs lorsqu'ils donnent
accès à leur profil qui est stocké sur votre site.
Ainsi, le serveur Express,
dans ce cas agissant comme l'application cliente,
va s'enregistrer sur Facebook et obtenir un ClientID et un secret client de Facebook.
Maintenant, lorsque le serveur Express s'inscrit sur Facebook,
vous devez avoir un compte sur Facebook,
un compte authentifié sur Facebook,
que vous utiliserez pour configurer cette application sur Facebook.
Ainsi, une fois que vous vous
inscrivez, vous aurez accès à un ID client et à un secret client.
Maintenant, le serveur de ressources,
comme je l'ai mentionné, est le serveur qui héberge les données protégées.
Données protégées signifiant le profil de l'utilisateur qui souhaite accéder au serveur Express.
Ainsi, le serveur Express veut accéder à ce serveur
de ressources et obtenir les données de profil de l'utilisateur qui veut accéder au serveur Express.
Donc, vous voyez la relation ici.
Donc, quand je parle d'une application cliente,
je ne parle pas de leur application frontale,
mais de leur serveur Express qui essaie de vous fournir
l'accès aux ressources qu'il a sur son site.
Mais le serveur Express,
afin de vous permettre d'y accéder,
aura besoin d'accéder à votre serveur de ressources Facebook qui
vous authentifiera et fournira vos informations de profil au serveur Express.
Donc, le serveur de ressources dont je parle ici,
est le serveur d'authentification OAuth 2 de Facebook
plus le serveur de ressources qui vous donne accès aux informations de profil de l'utilisateur.
Et le serveur d'autorisation est le serveur qui
autorisera quelqu'un à accéder
au serveur de ressources afin de récupérer les informations de profil.
Maintenant, l'utilisateur est celui qui a les informations de profil sur le serveur de ressources.
L' utilisateur doit autoriser le serveur Express à accéder
à ce serveur de ressources pour récupérer les informations de profil.
Mais si l'utilisateur doit autoriser le serveur Express,
l'utilisateur doit se connecter au compte Facebook,
puis obtenir des informations de Facebook appelé comme un jeton d'accès,
que l'utilisateur transmettra ensuite au serveur Express.
Maintenant, lorsque le jeton d'accès est obtenu à partir de Facebook via le protocole OAuth 2,
le jeton d'accès sera émis en termes
d'autorisation de cette application cliente ou du serveur Express,
qui est déjà enregistré sur Facebook en disant que
ce serveur client j'autoriserai à
accéder leurs informations de profil de leur fournisseur de services OAuth Facebook.
Donc, encore une fois, c'est un peu déroutant.
Nous verrons un diagramme où ce flux d'
informations vous est expliqué un peu plus clairement.
Un point que je viens de mentionner concerne un jeton OAuth ou le jeton d'accès.
Quel est ce jeton d'accès ?
Le jeton d'accès est quelque chose que le serveur d'autorisation émet pour vous.
Quel serveur d'autorisation ?
Il s'agit du serveur d'autorisation OAuth 2 tiers, le
serveur Facebook, dans cet exemple.
C' est donc une application serveur Express.
Maintenant, vous, en tant qu'utilisateur frontal,
voulez accéder à quelque chose à partir de l'application serveur Express.
L' application serveur Express vous dira que vous
vous authentifiez à partir de Facebook, puis obtenir le jeton d'accès de Facebook.
Ce jeton d'accès est émis à
l'utilisateur frontal à partir de Facebook lorsque l'utilisateur se connecte à son compte Facebook.
Maintenant, ce jeton d'accès est émis dans le nom de l'application cliente, le
serveur Express, qui a déjà enregistré sur Facebook.
Ainsi, pour que l'utilisateur accède à Facebook pour obtenir son jeton d'accès,
l'utilisateur a besoin de l'ID client de l'application cliente ou de l'application Express.
Cet ID client est donc intégré dans
l'application frontale que ce serveur Express vous servira.
Donc, le serveur Express sert un site Web auquel vous accédez,
alors ce site Web contiendra
le code dans lequel l'ID client de ce serveur Express est déjà intégré.
Une autre information que j'ai mentionnée est un secret client.
Maintenant, dans le flux d'authentification dont je vais parler,
le secret du client ne sera jamais révélé à personne.
Le secret client sera uniquement sur le côté serveur Express.
Lorsque le serveur Express tente d'authentifier et
d'obtenir l'accès au profil de l'utilisateur à partir de Facebook,
l'application cliente, le serveur Express
enverra à la fois l'ID client et le secret client,
ainsi que le jeton d'accès que l'utilisateur lui fournit à Facebook.
Et Facebook, à son tour,
autorise leur application cliente à accéder
au serveur de ressources afin d'obtenir les données de profil de l'utilisateur.
Et une fois que les données de profil de l'utilisateur sont obtenues à partir du serveur de ressources Facebook,
mon serveur Express va créer un compte
pour cet utilisateur particulier qui l'a connecté avec son compte Facebook.
Puis, par la suite, fournissez un jeton web JSON à
l'utilisateur,
que l'utilisateur peut ensuite utiliser pour accéder aux ressources stockées sur le serveur Express.
Donc, encore une fois, pour résumer cela,
j'ai un diagramme ici pour vous expliquer cela un peu plus en détail.
En plus de cela,
il y a aussi un jeton d'actualisation.
Lorsqu' un jeton d'accès est émis par le serveur Facebook OAuth 2,
le jeton d'accès a une durée de vie limitée.
Après cela, le jeton d'accès deviendra invalide.
Donc, le jeton d'accès doit rester confidentiel.
Donc, tout cet échange de jetons entre les différents sites
se fera dans une matière cryptée en utilisant le protocole HTTPS.
Assurez-vous donc que lorsque vous envoyez votre jeton d'accès de
votre application frontale utilisateur au serveur Express,
vous n'envoyez le jeton d'accès que via HTTPS, et non HTTP.
Ceci est très important parce que vous ne
voulez pas que votre jeton d'accès soit révélé à quiconque parce que
quiconque peut obtenir un de votre jeton d'accès peut prétendre être
son application cliente et ensuite accéder à votre profil utilisateur.
C' est donc très important.
Maintenant, puisque le jeton d'accès a une durée de vie limitée,
il existe également un jeton d'actualisation correspondant,
qui peut être utilisé pour actualiser un jeton d'accès expiré.
Maintenant, dans le type de flux que nous allons
utiliser avec notre application dans l'exercice,
nous ne serons pas en mesure d'utiliser le jeton d'actualisation.
Chaque fois que l'utilisateur veut autoriser
le serveur Express à aller chercher les informations de profil de Facebook,
l'utilisateur devra fournir explicitement
un nouveau jeton d'accès obtenu à partir de Facebook.
La seule partie que je viens de mentionner brièvement,
mais je n'ai pas élaboré,
est comment l'application cliente, le serveur Express,
les échelles, comment s'inscrivez-vous au fournisseur de services OAuth 2 ?
Maintenant, c'est là que de nombreux fournisseurs de services OAuth 2
fournissent un moyen d'enregistrer une application sur leur site.
Ainsi, une application cliente,
les serveurs Express dans notre exemple,
s'enregistrera en tant qu'application cliente sur le fournisseur de services OAuth.
Ainsi, comme vous le verrez dans l'exercice,
la toute première étape que nous ferons est de vous connecter à Facebook avec
notre compte et de créer une application sur le site Facebook.
Lorsque vous faites cela, Facebook vous enverra un ID d'application client et un secret client.
Cette procédure s'applique à de nombreux autres fournisseurs de services OAuth car il s'
agit du flux général dont parle le protocole OAuth 2.
Ainsi, l'ID de l'application client et le secret client sont utiles pour que nous puissions
prouver notre identité
au serveur OAuth lorsque nous transmettons un jeton d'accès que nous obtenons de l'utilisateur.
Maintenant, il y a aussi une URL de redirection que vous devez
enregistrer lorsque vous enregistrez l'application cliente,
et vous me verrez effectuer cela dans les étapes que j'enregistre
l'application sur le site Facebook.
Maintenant, pour résumer le flux d'information
dont nous venons de parler brièvement dans un cas antérieur,
permettez-moi de commencer par là.
Le premier point à examiner est le propriétaire de la ressource.
Donc, le propriétaire de la ressource ici
est l'utilisateur qui va utiliser son compte de médias sociaux.
Facebook, dans cet exemple,
a l'authentification pour l'utilisateur.
Ainsi, le propriétaire de la ressource est celui qui a le profil sur la ressource.
Et ces informations de profil pour chaque compte Facebook,
ils ont été stockés sur le serveur Facebook.
Et donc le serveur Facebook fournit le serveur de ressources ici.
C' est donc le fournisseur de services OAuth que vous voyez sur
le côté droit de cette image ici.
Imaginez donc que le serveur Facebook sur le côté droit, cette application cliente,
qui a le serveur API de repos,
le serveur Express que nous avons implémenté,
est une application cliente dans ce cas,
et le propriétaire de la ressource est l'utilisateur.
URL utilisateur frontal, qui va
vous autoriser à aller sur Facebook pour vérifier les informations d'identification de cet utilisateur.
Donc, lorsque vous voulez accéder aux informations du côté client,
vous devez d'abord aller
autoriser cette application cliente pour pouvoir
accéder aux informations de votre profil.
Donc, l'application cliente,
si elle agit comme une application web,
il fournira un bouton approprié là-dedans disant se connecter en utilisant Facebook.
Et donc, lorsque vous cliquez sur le bouton,
essentiellement, la première étape est initiée.
La demande d'autorisation utilisateur est lancée.
Ainsi, votre application cliente,
par l'intermédiaire de
l'agent utilisateur, l'agent utilisateur est essentiellement l'application cliente, l'application frontale.
Il pourrait
s'agir de l'application Angular que nous avons développée ou de cette application mobile, que ce soit Ionic ou qu'il s'agisse
d'une application NativeScript que nous avons développée dans les cours précédents dans
la spécialisation ou même d'une application native comme une application iOS ou une application Android.
Tous ces éléments agissent en tant qu'agent utilisateur.
Ainsi, l'agent utilisateur,
ils utilisent un processus de demande d'autorisation via
l'agent utilisateur au serveur d'autorisation,
qui est le serveur Facebook.
Maintenant, lorsque cela sera transmis,
le propriétaire de la ressource ou l'utilisateur,
qui essaie de donner accès à son profil à cette application cliente,
devra autoriser Facebook
à partager cette information avec l'application cliente.
Dans l'approche implicite de subvention de flux que nous utilisons dans
notre exemple ici et aussi dans l'exercice qui suit,
l'approche implicite de subvention de flux est
l'approche la plus appropriée lorsque vous implémentez une application web en utilisant
un framework comme Angular ou l'application mobile hybride
avec Ionic ou un NativeScript ou même une application native.
L' approche implicite de subvention de flux est beaucoup plus simple
d'utiliser l'OAuth 2 pour ce type d'applications.
Ainsi, le propriétaire de la ressource clique sur le bouton de connexion,
puis le serveur d'autorisation invitera le propriétaire de la ressource avec les informations indiquant :
« Cette application cliente veut accéder aux informations de votre profil.
Est-ce que vous l'autorisez ? »
Et donc cela sera apparu par Facebook,
et puis vous cliquez sur un bouton là disant, « Oui,
j'autorise cette application client à y accéder en mon nom. »
Donc, sur ce point,
le serveur d'autorisation sur Facebook,
le serveur d'autorisation OAuth 2 sur Facebook,
va générer un jeton d'accès.
Pour générer ce jeton d'accès,
il utilisera l'ID client de cette application cliente,
l'application serveur Express que nous enregistrons.
L' ID client doit donc faire partie de l'agent utilisateur utilisé par cet utilisateur.
Cet ID client sera donc intégré à l'application Angular, à
l'application Ionic ou NativeScript ou même à une application iOS ou Android.
Ainsi, l'ID client sera alors utilisé par
l'agent utilisateur pour tourner le serveur d'autorisation en disant :
« Cette application cliente veut accéder à mon profil,
et je suis prêt à vous autoriser à autoriser l'accès au profil. »
Ainsi, à ce stade,
le serveur d'autorisation enverra un jeton d'accès à l'agent utilisateur dans ce cas.
Donc, rappelez-vous, ce jeton d'accès entre dans l'agent utilisateur,
qui est l'application mobile ou leur application Angular qui est implémentée par nous.
Ensuite, cet agent utilisateur prendra ce jeton d'accès
, puis passera ce jeton d'accès à cette application cliente.
Donc, le OAuth pour se connecter,
mais le jeton d'accès sera transmis à l'application cliente,
le serveur Express dans ce cas,
à une route particulière sur le routeur de l'utilisateur,
la route d'authentification sur le site d'application cliente.
Maintenant, précédemment, nous avons vu l'utilisation de l'authentification locale,
où nous avons envoyé une demande de barre oblique utilisateur se connecter.
Maintenant, pour que cela fonctionne dans notre application,
nous allons en configurer un autre sur les utilisateurs barre oblique, barre
oblique Facebook, jeton barre oblique, et ainsi de suite.
Donc, une autre URL sur laquelle nous fournissons ce jeton d'accès sur le serveur Express.
Maintenant, lorsque ce jeton d'accès est obtenu par le serveur
Express, le serveur Express prendra ce jeton d'accès,
puis avec son ID client et le secret client,
il enverra ces informations au serveur d'autorisation.
Et le serveur d'autorisation permettra alors à son application cliente
d'accéder au serveur de ressources afin d'obtenir les informations de profil.
Ainsi, les informations de profil seront renvoyées à l'étape numéro six,
à l'application client dans ce cas.
Ainsi, lorsque l'application cliente obtient les informations de profil pour l'utilisateur,
l'application cliente crée un nouveau compte pour
l'utilisateur sur chaque site si aucun compte n'existe.
Si cet utilisateur s'est déjà connecté plus tôt à l'aide de son identifiant Facebook,
un compte existe déjà, de sorte que l'application cliente et le serveur de l'API
Rest vérifieront simplement que ce compte d'utilisateur existe déjà.
Et, à ce stade,
l'utilisateur est authentifié à la fonctionnalité de connexion tiers
fournie par le service d'authentification OAuth 2 de Facebook.
À ce stade, l'application cliente va générer un jeton Web JSON,
dans l'exemple que nous allons implémenter et exercer,
puis transmettre ce jeton Web JSON à l'agent utilisateur ou à l'application frontale, ou à l'application
Angular, ou à l'application Ionic,
ou à l'application NativeScript.
Ensuite, le jeton Web JSON sera utilisé par l'utilisateur
afin de s'authentifier chaque fois qu'il ou elle veut
accéder aux ressources stockées sur le serveur Express.
Ainsi, une fois que vous avez obtenu le jeton Web JSON,
toutes les opérations suivantes, vous avez déjà vu comment le faire avec JSON Web Token.
Ainsi, une fois que vous avez obtenu le jeton Web JSON
, votre travail est terminé,
puis vous pouvez poursuivre l'opération normale à partir de ce moment.
Maintenant, lorsque le jeton Web JSON expire,
vous devez passer par l'ensemble du processus de réauthentification et,
par la suite, permettre aux utilisateurs d'accéder aux informations de votre site.
Donc, avec cette compréhension rapide du fonctionnement des opérations OAuth 2,
encore une fois, comme vous le voyez, il y a beaucoup de détails ici.
Mais, heureusement, nous n'avons pas à traiter tous ces détails parce que nous allons
utiliser un module de noeud qui s'occupe de beaucoup de ces détails en notre nom.
Puisque nous avons déjà configuré notre serveur Express pour utiliser Passport,
nous pouvons maintenant utiliser un autre code de module de nœud comme module Passport-Facebook-Token.
Le module Passport-Facebook-Token implémente essentiellement
l'approche implicite de subvention dont j'ai parlé plus tôt.
Ensuite, vous pouvez initialiser
une nouvelle stratégie dans votre stratégie Passport, dans votre application.
De plus, le module Passport-Facebook-Token vous permet de configurer
une nouvelle stratégie d'authentification Passport pour utiliser l'API OAuth 2 basée sur Facebook.
Et donc pour utiliser ce module,
vous installez ceci en disant passé npm installer passeport- facebook-jeton,
moins moins enregistrer, et puis une fois que vous avez installé cela,
vous allez configurer une stratégie Facebook dans votre application, et, par la suite,
faire usage de cela pour configurer la stratégie pour
utiliser votre passeport si nous utilisons l'authentification basée sur OAuth 2 pour notre application.
Avec cette compréhension rapide de OAuth 2,
passons à l'exercice,
où nous allons configurer notre serveur Express pour utiliser effectivement
cette approche implicite de subvention pour nous permettre de
vérifier notre identité sur le serveur Express et,
par la suite, d'accéder aux ressources, aux plats,
les promotions et les informations des leaders qui sont stockées sur notre serveur Express.