‫Instructeur : Nous avons donc configuré notre
‫modèle d'utilisateur pour enregistrer les utilisateurs avec des mots de passe sécurisés.
‫Et donc ensuite, nous allons
‫vraiment implémenter l'authentification et l'autorisation des utilisateurs.
‫Donc, en termes simples, l'ensemble du flux de
‫travail consistant à connecter les utilisateurs
‫et à leur permettre d'interagir avec certaines ressources protégées
‫auxquelles les utilisateurs non connectés ne peuvent pas accéder.
‫Il existe maintenant de nombreuses méthodes d'authentification,
‫mais celle que nous allons utiliser est une approche
‫très moderne, simple et sécurisée appelée Json Web Tokens ou JWT en abrégé.
‫Les jetons Web Json sont donc une solution sans
‫état pour l'authentification.
‫Il n'est donc pas nécessaire de stocker un état de session sur le
‫serveur, ce qui est bien sûr parfait pour des API reposantes comme celle
‫que nous construisons.
‫Parce que rappelez-vous, les API reposantes doivent toujours être sans état.
‫Et l'alternative la plus largement utilisée à l'authentification avec
‫les JWT consiste simplement à stocker l'état de connexion de l'utilisateur sur
‫le serveur à l'aide de sessions.
‫Mais bien sûr, cela ne suit pas le
‫principe qui dit que les API reposantes doivent être sans état
‫et c'est pourquoi nous optons pour une solution comme les JWT.
‫Voyons maintenant comment l'authentification fonctionne réellement
‫avec les jetons Web Json.
‫Et en supposant que nous ayons déjà un utilisateur enregistré
‫dans notre base de données, c'est ainsi qu'un utilisateur se connecte à l'application.
‫Ainsi, le client de l'utilisateur commence par faire une demande
‫de publication avec le nom d'utilisateur ou l'e-mail et le mot de passe.
‫L'application vérifie alors si l'utilisateur existe et si le
‫mot de passe est correct.
‫Et si tel est le cas, un jeton Web
‫Json unique pour cet utilisateur uniquement est créé à l'aide d'une
‫chaîne secrète stockée sur un serveur.
‫Et un JWT lui-même n'est en réalité qu'une chaîne
‫qui ressemble à ceci.
‫Mais nous allons parler davantage du JWT lui-même
‫dans la diapositive suivante.
‫Quoi qu'il en soit, le serveur renvoie ensuite ce JWT au client qui le
‫stockera soit dans un cookie, soit dans un stockage local.
‫Et juste comme ça, l'utilisateur est authentifié
‫et essentiellement connecté à notre
‫application sans laisser d'état sur le serveur.
‫Ainsi, le serveur ne sait en fait pas quels
‫utilisateurs sont réellement connectés.
‫Mais bien sûr, l'utilisateur sait qu'il est
‫connecté car il dispose d'un Json Web Token valide qui est
‫un peu comme un passeport pour accéder aux parties protégées de l'application.
‫Encore une fois, juste pour être sûr que vous avez bien compris.
‫Un utilisateur est connecté dès qu'il récupère
‫son jeton Web Json unique et valide qui n'est enregistré nulle part
‫sur le serveur.
‫Et donc ce processus est donc complètement apatride.
‫Ensuite, chaque fois qu'un utilisateur souhaite accéder à une route protégée, comme
‫ses données de profil utilisateur, par
‫exemple, il envoie son jeton Web Json avec une demande.
‫Donc c'est un peu comme montrer son passeport pour avoir
‫accès à cette route, non ?
‫Et c'est probablement la meilleure et la plus simple façon de
‫comprendre toute cette idée.
‫Désormais, une fois que la demande atteint le
‫serveur, notre application vérifiera si le jeton Web Json
‫est réellement valide.
‫Donc, si l'utilisateur est vraiment celui qu'il prétend être.
‫Et plus sur le fonctionnement de cette étape
‫un peu plus loin dans cette vidéo.
‫Maintenant, si le jeton est réellement valide,
‫eh bien, les données demandées seront envoyées au client et
‫sinon, il y aura une erreur indiquant à l'utilisateur
‫qu'il n'est pas autorisé à accéder à cette ressource.
‫Et tant que l'utilisateur est connecté, c'est ainsi
‫que cela fonctionnera à chaque fois qu'il demandera des données à
‫n'importe quel itinéraire protégé.
‫Maintenant, ce qui est très important
‫à noter ici, c'est que toute cette communication doit se faire via https.
‫Sécurisez donc http crypté afin d'empêcher que quiconque puisse
‫accéder aux mots de passe ou aux jetons Web Json.
‫Alors seulement, nous avons un système vraiment sécurisé.
‫Mais nous en parlerons plus tard dans la section, d'accord.
‫Je sais donc que cela peut sembler assez
‫déroutant au début lorsque
‫vous essayez d'abord de comprendre, mais
‫en fait, le principe lui-même est en fait assez simple, d'accord ?
‫Et c'est vraiment tout ce
‫que vous devez savoir pour pouvoir implémenter l'authentification à l'aide de JWT.
‫Mais penchons-nous maintenant un peu
‫plus sur le fonctionnement réel du JWT lui-même.
‫Ainsi, un jeton Web Json ressemble à la partie gauche de cette capture d'écran qui a
‫été prise à partir du débogueur JWT de jwt. io.
‫Il s'agit donc essentiellement d'une chaîne d'encodage
‫composée de trois parties.
‫L'en-tête, la charge utile et la signature.
‫Maintenant, l'en-tête n'est que quelques métadonnées sur le jeton lui-même et la
‫charge utile est les données que nous pouvons
‫encoder dans le jeton, toutes les données que nous voulons vraiment.
‫Ainsi, plus nous voulons encoder de données
‫ici, plus le JWT est important.
‫Quoi qu'il en soit, ces deux parties ne sont
‫que du texte brut qui sera encodé, mais pas crypté.
‫Ainsi, n'importe qui pourra les décoder et les lire.
‫Nous ne pouvons donc pas stocker de données sensibles ici.
‫Mais ce n'est pas du
‫tout un problème car dans la troisième partie, donc dans la
‫signature, c'est là que les choses deviennent vraiment intéressantes.
‫La signature est créée à l'aide de l'en-tête, de la charge
‫utile et du secret enregistré sur le serveur.
‫Vous vous en souvenez ?
‫Et tout ce processus est
‫alors appelé signature du jeton Web Json.
‫Encore une fois, l'algorithme de signature prend l'en-tête,
‫la charge utile et le secret pour créer une signature unique.
‫Donc seules ces données plus le
‫secret peuvent créer cette signature, d'accord ?
‫Ensuite, avec l'en-tête et la charge
‫utile, ces signatures forment le JWT, qui
‫est ensuite envoyé au client.
‫Maintenant, comme je l'ai mentionné brièvement, dès la première
‫diapositive, une fois que le serveur reçoit un JWT pour autoriser
‫l'accès à une route protégée, il doit le vérifier
‫afin de déterminer si l'utilisateur est vraiment celui
‫qu'il prétend être, n'est-ce pas ?
‫En d'autres termes, il vérifiera si personne n'a modifié l'en-tête et
‫les données de charge utile du jeton.
‫Encore une fois, cette étape de vérification vérifiera si
‫aucun tiers n'a réellement modifié l'en-tête ou la
‫charge utile du jeton Web Json.
‫Alors, comment cette vérification fonctionne-t-elle réellement ?
‫Eh bien, c'est en fait assez simple.
‫Ainsi, une fois le JWT reçu, la
‫vérification prendra son en-tête et sa charge utile
‫et, avec le secret toujours
‫enregistré sur le serveur, créera essentiellement une signature de test.
‫Mais la signature originale qui a été générée
‫lors de la création du JWT est toujours dans le jeton, n'est-ce pas ?
‫Et c'est la clé de cette vérification.
‫Car il ne nous reste plus
‫qu'à comparer la signature de test avec la signature d'origine.
‫Et si la signature de test est
‫la même que la signature d'origine, cela signifie que la charge
‫utile et l'en-tête n'ont pas été modifiés, n'est-ce pas ?
‫Car s'ils avaient été
‫modifiés, la signature de test devrait être différente.
‫Donc dans ce cas où il n'y a
‫pas eu d'altération des données, on peut alors authentifier l'utilisateur.
‫Et bien sûr, si les
‫deux signatures sont réellement différentes, eh bien, cela
‫signifie que quelqu'un a falsifié les données.
‫Habituellement en essayant de changer la charge utile.
‫Mais ce tiers manipulant la charge utile
‫n'a bien sûr pas accès au secret, il ne
‫peut donc pas signer le JWT.
‫Ainsi, la signature originale ne correspondra jamais
‫aux données manipulées.
‫Et par conséquent, la vérification échouera toujours
‫dans ce cas.
‫Et c'est la clé pour faire fonctionner tout ce système.
‫C'est la magie qui rend JWT si
‫simple, mais aussi extrêmement puissant.
‫Alors permettez-moi de le résumer à nouveau.
‫Sans le secret, personne ne pourra manipuler les données
‫JWT car ils ne peuvent pas créer de
‫signature valide pour les nouvelles données.
‫Je veux dire qu'ils pourraient bien sûr
‫manipuler les données, mais cela échouera toujours à l'étape de vérification.
‫Maintenant, ne vous inquiétez pas, nous n'allons pas
‫réellement implémenter ces algorithmes JWT par nous-mêmes.
‫Ils sont très complexes et nous
‫n'allons pas réinventer la roue ici, d'accord ?
‫Mais il est toujours très important de comprendre comment
‫tout ce processus fonctionne en coulisse.
‫Et j'espère que cette conférence a fait exactement cela pour vous.
‫Mais maintenant, passons à la prochaine conférence pour réellement
‫commencer à utiliser tout cela.