[MUSIQUE]
Dans les leçons précédentes,
nous avons vu plusieurs types de systèmes d'authentification différents.
Nous avons commencé par l'authentification de base, puis nous avons examiné comment nous pouvons utiliser les cookies pour
effectuer l'authentification, et même les cookies signés, et
par la suite, nous avons examiné l'authentification basée sur la session.
Où le serveur garde une trace des informations sur chaque client,
puis le cookie sera utilisé comme un moyen d'indexation dans la
base de données côté serveur pour extraire des informations supplémentaires, pour valider l'utilisateur.
Maintenant, les authentifications basées sur les cookies et les sessions ne sont pas évolutives,
car le serveur doit garder une trace de tous les utilisateurs différents.
Même si, cela est fait en dehors du protocole HTTP lui-même,
mais le fait que vous devez garder une trace
de toutes les informations de section du site du serveur, le rend pas très évolutif.
C' est donc là que l'authentification basée sur des jetons
s'est révélée très utile.
nous allons examiner l'authentification de base de jetons un peu plus en détail dans cette conférence et
l'exercice qui suit.
Encore une fois, examiner rapidement les cookies et l'authentification basée sur la session.
Avec l'authentification basée
sur les cookies, nous remarquons que les cookies sont stockés du côté client, et les cookies sont inclus
dans chaque message de demande sortante, où, le serveur est rappelé à
ce client spécifique, en extrayant des informations à partir du cookie. Le
cookie peut être utilisé avec des sessions, dans lesquelles les cookies stockent l'ID de session,
puis lorsque le serveur reçoit la requête entrante du cookie,
il extrait l'ID de session et l'utilise comme index dans le
magasin de session côté serveur pour récupérer les informations de session pour le client particulier.
Maintenant, cette approche, comme je l'ai dit,
n'est pas très évolutive car si vous avez des milliers de sessions, le serveur doit
garder une trace de toutes ces milliers de sessions côté serveur.
Même si cela est fait indépendamment de HTTP dans un magasin,
soit un magasin de fichiers ou une base de données.
Mais encore,
le fait que vous avez besoin de suivre toutes ces informations rend ces informations non évolutives.
Donc, encore une fois, pour vous rappeler une fois,
pourquoi parlons-nous d'authentification basée sur des jetons ?
L' authentification basée sur la session, comme nous l'avons vu précédemment, fonctionne parfaitement bien pour les
applications Web et peut facilement prendre en charge l'authentification des utilisateurs.
Mais alors, l'authentification basée sur la session, alors que c'est le principe des
serveurs sans état et conduit également à des problèmes d'évolutivité.
Le deuxième problème est que les applications mobiles ne
gèrent pas très bien les authentifications basées sur une session.
De même, les applications mobiles ont du mal à traiter les cookies.
Ainsi, dans de telles circonstances où votre serveur sert des données à la
fois pour une application Web, ainsi qu'une application mobile.
Ensuite, l'authentification basée sur la session ne sera pas très utile, et
c'est là que l'authentification basée sur les jetons devient beaucoup plus facile à utiliser.
Dans une authentification basée sur un jeton comme nom en place,
le serveur émettra un jeton à un utilisateur validé, et toutes les
demandes suivantes venant du côté client, porteront le jeton dans la requête elle-même.
Soit sous la forme d'un en-tête de requête, soit dans le corps du message de requête.
De plus, l'authentification basée sur des jetons nous aide également à
traiter ce que l'on appelle des problèmes CORS ou CSRF.
Problèmes de partage de ressources d'origine croisée et ainsi de suite
, je vais parler brièvement du coût dans le module suivant.
Mais pour le moment, l'authentification basée sur des jetons résout certains
des problèmes qui se posent avec les voitures et les problèmes liés à la falsification des requêtes intersites.
Non seulement cela, l'authentification basée sur des jetons est beaucoup plus facile pour
une application de partager son authentification avec une autre application.
Bien sûr, tout cela est fait de manière sécurisée.
Mais, avec l'authentification basée sur la session, ce n'est pas simple.
Comment fonctionne l'authentification basée sur les jetons ?
Dans l'authentification basée sur
des jetons, l'utilisateur doit d'abord se valider du côté serveur.
Maintenant, cette validation pourrait prendre les formes que nous avons vues plus tôt.
Nous pouvons donc utiliser une validation locale en utilisant le nom d'utilisateur et le mot de passe.
Ou, nous pouvons même utiliser la validation par des tiers en utilisant
des technologies comme, oauth ou oauth 2.0 ou open ID.
Nous allons parler brièvement de oauth et oauth 2.0 dans le prochain module.
Mais, quelle que soit la manière dont l'utilisateur s'authentifie, une fois l'utilisateur
authentifié, juste après, votre serveur peut simplement émettre un jeton à l'utilisateur.
Et toute communication ultérieure entre l'utilisateur et
le serveur, peut être fait simplement en utilisant ce jeton.
JSON Web Token dont nous parlerons, est un tel
schéma d'authentification basé sur des jetons, et là serveur quand il crée ce jeton, il va créer un jeton signé.
Utilisation d'un secret sur le site du serveur que seul le serveur connaît.
Ainsi, même si un tiers entre et et
tente de manipuler le jeton, même s'il capture le jeton et
essaie de le manipuler, le jeton deviendra invalide.
Et donc, cette façon de protéger l'utilisateur est
facilement faisable, toutes les demandes ultérieures
du côté client devraient porter le jeton dans la requête,
soit, comme je l'ai dit, dans l'en-tête ou dans le corps du message de requête.
Ainsi, lorsque le serveur reçoit ce jeton, le serveur vérifiera le jeton,
pour s'assurer qu'il s'agit d'un jeton valide, puis s'il s'agit d'un jeton valide,
le serveur répondra alors à la demande entrante.
Comme je l'ai mentionné, JSON Web Tokens est un tel schéma d'authentification basé sur des jetons.
JSON Web Token, est un moyen très simple d'encoder des
informations dans un jeton puis de les transmettre au site client.
JSON Web Token lui-même est basé sur des normes,
ceci est basé sur l'IETF RFC 7519.
IETF ici, signifie l'Internet Engineering Task Force.
L' organisation qui commande tout sur le fonctionnement de l'Internet,
et traite des protocoles et des politiques, liés à Internet.
Le RFC, signifie le document de normes,
en termes IETF, RFC signifie Request for Comments.
Et chacun de ces documents de normes porte un numéro.
7519 dans ce cas fait référence au document,
le document standard lié à JSON Web Token.
Le jeton Web JSON lui-même est un jeton autonome, il transporte toutes
les informations en lui-même, ce qui est nécessaire pour identifier l'utilisateur.
Non seulement cela, un jeton Web JSON peut être partagé entre deux applications.
Ainsi, par exemple, une application lorsqu'elle s'authentifie et obtient ensuite
un jeton Web JSON, peut transmettre ce jeton Web JSON à et dans cette application,
qu'elle est prête à autoriser à accéder au serveur en son nom.
Ce partage du jeton se fait d'une manière très sécurisée,
alors ne vous inquiétez pas trop de sécurité là-dedans.
Ce n'est pas d'une manière sécurisée,
où par le partage du jeton entre une application à une autre.
Ainsi, l'autorisation est transférée vers une deuxième application, et
la seconde application peut autoriser au nom de la première application,
à communiquer avec le serveur.
Ceci est faisable avec des jetons.
Maintenant, bien sûr, l'ingénieur en vous se demandera évidemment ce qu'il y a exactement
à l'intérieur d'un jeton Web JSON, et comment est-il utile ?
Un jeton Web JSON, comme je l'ai dit, est encodé dans une longue chaîne et
cette chaîne elle-même peut être interprétée comme composée de trois parties.
La chaîne elle-même peut, ou la chaîne codée elle-même contient trois parties,
l'en-tête, la charge utile et la signature.
Cela contient suffisamment d'informations sur la façon dont ce jeton est codé.
L' en-tête lui-même contient l'algorithme spécifique utilisé pour
coder ce jeton Web JSON, et le type du jeton lui-même.
L' algorithme dans ce cas, serait HS256 qui est un schéma d'encodage 256 bits,
qui est utilisé pour hacher les informations à l'intérieur du jeton.
Et dans ce cas, il se trouve que c'est le jeton Web JSON, et donc
le champ type sera défini sur JWT.
Et c'est donc l'information qui est stockée dans l'en-tête de JSON Web Token.
La charge utile elle-même, contient des informations qui vous aident à identifier l'utilisateur.
Dans l'exercice que nous allons faire,
la charge utile horaire ne porte que l'ID de l'utilisateur à l'intérieur de la charge utile.
Aucune autre information n'est nécessaire.
Cet ID peut être utilisé côté serveur,
pour indexer dans la base de données Mongo pour récupérer les informations complètes de l'utilisateur si nécessaire.
Donc, vous verrez que nous allons encoder l'ID
puis le stocker dans la charge utile de ce message.
Vous pouvez stocker des informations supplémentaires dans la charge utile du message si vous le souhaitez.
Mais plus vous y stockez d'informations,
plus le jeton Web JSON correspondant va à moi.
Donc, essayez de limiter la quantité d'informations que vous avez stockées dans la charge utile
du jeton Web JSON.
Comme nous le verrons dans l'exercice, nous avons un module de nœud qui nous
permet d'encoder et de créer un jeton Web JSON,
basé sur les informations que nous voulons mettre dans la charge utile.
Maintenant, lorsque vous créez un jeton Web JSON, vous fournissez également une signature.
Une clé secrète du côté serveur qui est utilisée pour coder ce jeton Web JSON,
et ce secret est également inclus dans la partie signature du jeton Web JSON.
La signature elle-même est incluse de telle sorte qu'il y ait
une base avant l'en-tête codé et la charge utile,
qui est ensuite encodé en utilisant le secret spécifique utilisé par le serveur.
Et cela encodé dans, comme je l'ai dit le HMAC,
que nous avons fait référence dans l'une des leçons précédentes et
en utilisant le hachage 256 bits, et qui est inclus dans la signature.
Ainsi, lorsque ce jeton Web JSON est reçu côté serveur, et
lorsque le serveur décode ce jeton, le serveur est capable de
vérifier que ce jeton Web JSON n'a pas été altéré par personne,
alors que le jeton est passé entre le client et le site du serveur.
Donc, si vous savez quelque chose sur la sécurité, et les intrus,
et ainsi de suite, vous comprenez pourquoi il est important d'encoder le jeton, et de
vérifier l'authenticité du jeton sur le site du serveur.
Comme je l'ai mentionné, si vous avez besoin de traiter les jetons Web JSON dans votre application de nœud.
Il existe un module de nœud spécifique appelé le module de nœud jsonwebtoken.
Ce module de nœud implémente les normes liées au jeton Web JSON, et
il peut être inclus dans votre application de nœud.
Ce module lui-même, fournit une méthode appelée signe qui vous permet de signer et d'
émettre le jeton au client à partir du côté serveur.
Il contient également une méthode de vérification.
Qui peut être utilisé pour vérifier l'authenticité ou
pour assurer l'authenticité du jeton Web JSON entrant,
donc nous allons utiliser le module de jeton Web JSON, dans notre exercice.
Avec le module JSON Web Token,
nous avons également utilisé le module Passport-JWT, module nœud.
Ce qui fournit les stratégies basées sur JWT pour notre module d'authentification de passeport.
Cela fournit donc une stratégie de passeport pour l'authentification à l'aide du jeton Web JSON.
Cela vous permet donc d'authentifier le point de terminaison RESTful en utilisant le JWT comme méthode de
validation dong, sans nécessiter que le serveur utilise des sessions.
Maintenant, le module de passeport JWT
prend en charge une méthode permettant même d'extraire le jeton JWT
du message de demande entrante, puis même de vérifier le jeton en votre nom.
Le stagiaire du module Passport-JWT utilise le module JSON Web Token pour
effectuer la vérification de ce jeton Web JSON.
Le jeton lui-même peut être porté dans l'en-tête de la requête entrante,
dans l'en-tête, même dans l'en-tête d'authentification de la requête entrante, ce
qui est ce que nous allons faire dans l'exercice.
Le jeton peut également être transporté dans le corps de la demande entrante, auquel cas,
nous devons extraire le jeton du corps de la demande entrante
, puis en faire usage.
Le module Passport-JWT prend également en charge cela si vous choisissez de l'
utiliser comme moyen de transmettre le jeton du client au site serveur.
Le jeton Web JSON, peut également être inclus dans les paramètres de requête URL si vous le
choisissez, et peut être extrait de là b Passport-JWT et
utilisé pour l'authentification.
Maintenant, avec cette compréhension rapide des jetons Web JSON et de
leur utilité, nous allons passer à l'exercice où nous allons utiliser
le module Passport-JWT, avec le module JSON Web Token,
et configurer notre serveur d'API Express Rest pour utiliser JSON Web Tokens.
[ MUSIQUE]