1
00:00:00,930 --> 00:00:03,210
‫Instructeur : Nous avons donc configuré notre

2
00:00:03,210 --> 00:00:06,440
‫modèle d'utilisateur pour enregistrer les utilisateurs avec des mots de passe sécurisés.

3
00:00:06,440 --> 00:00:08,850
‫Et donc ensuite, nous allons

4
00:00:08,850 --> 00:00:11,670
‫vraiment implémenter l'authentification et l'autorisation des utilisateurs.

5
00:00:11,670 --> 00:00:14,230
‫Donc, en termes simples, l'ensemble du flux de

6
00:00:14,230 --> 00:00:16,530
‫travail consistant à connecter les utilisateurs

7
00:00:16,530 --> 00:00:19,360
‫et à leur permettre d'interagir avec certaines ressources protégées

8
00:00:19,360 --> 00:00:22,163
‫auxquelles les utilisateurs non connectés ne peuvent pas accéder.

9
00:00:23,100 --> 00:00:26,050
‫Il existe maintenant de nombreuses méthodes d'authentification,

10
00:00:26,050 --> 00:00:29,360
‫mais celle que nous allons utiliser est une approche

11
00:00:29,360 --> 00:00:34,360
‫très moderne, simple et sécurisée appelée Json Web Tokens ou JWT en abrégé.

12
00:00:35,170 --> 00:00:38,100
‫Les jetons Web Json sont donc une solution sans

13
00:00:38,100 --> 00:00:39,500
‫état pour l'authentification.

14
00:00:39,500 --> 00:00:43,410
‫Il n'est donc pas nécessaire de stocker un état de session sur le

15
00:00:43,410 --> 00:00:47,360
‫serveur, ce qui est bien sûr parfait pour des API reposantes comme celle

16
00:00:47,360 --> 00:00:48,580
‫que nous construisons.

17
00:00:48,580 --> 00:00:53,080
‫Parce que rappelez-vous, les API reposantes doivent toujours être sans état.

18
00:00:53,080 --> 00:00:56,300
‫Et l'alternative la plus largement utilisée à l'authentification avec

19
00:00:56,300 --> 00:01:00,240
‫les JWT consiste simplement à stocker l'état de connexion de l'utilisateur sur

20
00:01:00,240 --> 00:01:02,420
‫le serveur à l'aide de sessions.

21
00:01:02,420 --> 00:01:05,150
‫Mais bien sûr, cela ne suit pas le

22
00:01:05,150 --> 00:01:08,700
‫principe qui dit que les API reposantes doivent être sans état

23
00:01:08,700 --> 00:01:12,293
‫et c'est pourquoi nous optons pour une solution comme les JWT.

24
00:01:13,130 --> 00:01:15,960
‫Voyons maintenant comment l'authentification fonctionne réellement

25
00:01:15,960 --> 00:01:18,660
‫avec les jetons Web Json.

26
00:01:18,660 --> 00:01:21,600
‫Et en supposant que nous ayons déjà un utilisateur enregistré

27
00:01:21,600 --> 00:01:25,380
‫dans notre base de données, c'est ainsi qu'un utilisateur se connecte à l'application.

28
00:01:25,380 --> 00:01:28,700
‫Ainsi, le client de l'utilisateur commence par faire une demande

29
00:01:28,700 --> 00:01:32,330
‫de publication avec le nom d'utilisateur ou l'e-mail et le mot de passe.

30
00:01:32,330 --> 00:01:35,400
‫L'application vérifie alors si l'utilisateur existe et si le

31
00:01:35,400 --> 00:01:37,430
‫mot de passe est correct.

32
00:01:37,430 --> 00:01:40,340
‫Et si tel est le cas, un jeton Web

33
00:01:40,340 --> 00:01:44,010
‫Json unique pour cet utilisateur uniquement est créé à l'aide d'une

34
00:01:44,010 --> 00:01:46,290
‫chaîne secrète stockée sur un serveur.

35
00:01:46,290 --> 00:01:49,410
‫Et un JWT lui-même n'est en réalité qu'une chaîne

36
00:01:49,410 --> 00:01:51,150
‫qui ressemble à ceci.

37
00:01:51,150 --> 00:01:54,170
‫Mais nous allons parler davantage du JWT lui-même

38
00:01:54,170 --> 00:01:55,770
‫dans la diapositive suivante.

39
00:01:55,770 --> 00:02:00,440
‫Quoi qu'il en soit, le serveur renvoie ensuite ce JWT au client qui le

40
00:02:00,440 --> 00:02:04,160
‫stockera soit dans un cookie, soit dans un stockage local.

41
00:02:04,160 --> 00:02:06,930
‫Et juste comme ça, l'utilisateur est authentifié

42
00:02:06,930 --> 00:02:09,570
‫et essentiellement connecté à notre

43
00:02:09,570 --> 00:02:12,720
‫application sans laisser d'état sur le serveur.

44
00:02:12,720 --> 00:02:16,310
‫Ainsi, le serveur ne sait en fait pas quels

45
00:02:16,310 --> 00:02:17,930
‫utilisateurs sont réellement connectés.

46
00:02:17,930 --> 00:02:20,960
‫Mais bien sûr, l'utilisateur sait qu'il est

47
00:02:20,960 --> 00:02:25,040
‫connecté car il dispose d'un Json Web Token valide qui est

48
00:02:25,040 --> 00:02:29,270
‫un peu comme un passeport pour accéder aux parties protégées de l'application.

49
00:02:29,270 --> 00:02:32,470
‫Encore une fois, juste pour être sûr que vous avez bien compris.

50
00:02:32,470 --> 00:02:35,330
‫Un utilisateur est connecté dès qu'il récupère

51
00:02:35,330 --> 00:02:39,720
‫son jeton Web Json unique et valide qui n'est enregistré nulle part

52
00:02:39,720 --> 00:02:41,030
‫sur le serveur.

53
00:02:41,030 --> 00:02:44,840
‫Et donc ce processus est donc complètement apatride.

54
00:02:44,840 --> 00:02:49,300
‫Ensuite, chaque fois qu'un utilisateur souhaite accéder à une route protégée, comme

55
00:02:49,300 --> 00:02:51,940
‫ses données de profil utilisateur, par

56
00:02:51,940 --> 00:02:55,360
‫exemple, il envoie son jeton Web Json avec une demande.

57
00:02:55,360 --> 00:02:58,480
‫Donc c'est un peu comme montrer son passeport pour avoir

58
00:02:58,480 --> 00:03:00,450
‫accès à cette route, non ?

59
00:03:00,450 --> 00:03:03,870
‫Et c'est probablement la meilleure et la plus simple façon de

60
00:03:03,870 --> 00:03:05,320
‫comprendre toute cette idée.

61
00:03:05,320 --> 00:03:07,910
‫Désormais, une fois que la demande atteint le

62
00:03:07,910 --> 00:03:11,140
‫serveur, notre application vérifiera si le jeton Web Json

63
00:03:11,140 --> 00:03:12,580
‫est réellement valide.

64
00:03:12,580 --> 00:03:15,760
‫Donc, si l'utilisateur est vraiment celui qu'il prétend être.

65
00:03:15,760 --> 00:03:17,710
‫Et plus sur le fonctionnement de cette étape

66
00:03:17,710 --> 00:03:19,660
‫un peu plus loin dans cette vidéo.

67
00:03:19,660 --> 00:03:22,710
‫Maintenant, si le jeton est réellement valide,

68
00:03:22,710 --> 00:03:26,210
‫eh bien, les données demandées seront envoyées au client et

69
00:03:26,210 --> 00:03:29,400
‫sinon, il y aura une erreur indiquant à l'utilisateur

70
00:03:29,400 --> 00:03:32,600
‫qu'il n'est pas autorisé à accéder à cette ressource.

71
00:03:32,600 --> 00:03:34,880
‫Et tant que l'utilisateur est connecté, c'est ainsi

72
00:03:34,880 --> 00:03:38,230
‫que cela fonctionnera à chaque fois qu'il demandera des données à

73
00:03:38,230 --> 00:03:39,843
‫n'importe quel itinéraire protégé.

74
00:03:40,840 --> 00:03:43,000
‫Maintenant, ce qui est très important

75
00:03:43,000 --> 00:03:47,570
‫à noter ici, c'est que toute cette communication doit se faire via https.

76
00:03:47,570 --> 00:03:51,510
‫Sécurisez donc http crypté afin d'empêcher que quiconque puisse

77
00:03:51,510 --> 00:03:55,840
‫accéder aux mots de passe ou aux jetons Web Json.

78
00:03:55,840 --> 00:03:59,090
‫Alors seulement, nous avons un système vraiment sécurisé.

79
00:03:59,090 --> 00:04:02,430
‫Mais nous en parlerons plus tard dans la section, d'accord.

80
00:04:02,430 --> 00:04:05,120
‫Je sais donc que cela peut sembler assez

81
00:04:05,120 --> 00:04:06,900
‫déroutant au début lorsque

82
00:04:06,900 --> 00:04:09,120
‫vous essayez d'abord de comprendre, mais

83
00:04:09,120 --> 00:04:13,490
‫en fait, le principe lui-même est en fait assez simple, d'accord ?

84
00:04:13,490 --> 00:04:15,830
‫Et c'est vraiment tout ce

85
00:04:15,830 --> 00:04:20,370
‫que vous devez savoir pour pouvoir implémenter l'authentification à l'aide de JWT.

86
00:04:20,370 --> 00:04:22,740
‫Mais penchons-nous maintenant un peu

87
00:04:22,740 --> 00:04:25,880
‫plus sur le fonctionnement réel du JWT lui-même.

88
00:04:25,880 --> 00:04:30,310
‫Ainsi, un jeton Web Json ressemble à la partie gauche de cette capture d'écran qui a

89
00:04:30,310 --> 00:04:35,310
‫été prise à partir du débogueur JWT de jwt. io.

90
00:04:35,940 --> 00:04:38,650
‫Il s'agit donc essentiellement d'une chaîne d'encodage

91
00:04:38,650 --> 00:04:40,430
‫composée de trois parties.

92
00:04:40,430 --> 00:04:44,140
‫L'en-tête, la charge utile et la signature.

93
00:04:44,140 --> 00:04:47,910
‫Maintenant, l'en-tête n'est que quelques métadonnées sur le jeton lui-même et la

94
00:04:47,910 --> 00:04:50,910
‫charge utile est les données que nous pouvons

95
00:04:50,910 --> 00:04:54,470
‫encoder dans le jeton, toutes les données que nous voulons vraiment.

96
00:04:54,470 --> 00:04:56,690
‫Ainsi, plus nous voulons encoder de données

97
00:04:56,690 --> 00:04:58,890
‫ici, plus le JWT est important.

98
00:04:58,890 --> 00:05:01,750
‫Quoi qu'il en soit, ces deux parties ne sont

99
00:05:01,750 --> 00:05:04,860
‫que du texte brut qui sera encodé, mais pas crypté.

100
00:05:04,860 --> 00:05:08,790
‫Ainsi, n'importe qui pourra les décoder et les lire.

101
00:05:08,790 --> 00:05:11,730
‫Nous ne pouvons donc pas stocker de données sensibles ici.

102
00:05:11,730 --> 00:05:13,460
‫Mais ce n'est pas du

103
00:05:13,460 --> 00:05:16,580
‫tout un problème car dans la troisième partie, donc dans la

104
00:05:16,580 --> 00:05:19,370
‫signature, c'est là que les choses deviennent vraiment intéressantes.

105
00:05:19,370 --> 00:05:22,990
‫La signature est créée à l'aide de l'en-tête, de la charge

106
00:05:22,990 --> 00:05:26,020
‫utile et du secret enregistré sur le serveur.

107
00:05:26,020 --> 00:05:27,080
‫Vous vous en souvenez ?

108
00:05:27,080 --> 00:05:28,760
‫Et tout ce processus est

109
00:05:28,760 --> 00:05:30,883
‫alors appelé signature du jeton Web Json.

110
00:05:31,900 --> 00:05:35,590
‫Encore une fois, l'algorithme de signature prend l'en-tête,

111
00:05:35,590 --> 00:05:40,590
‫la charge utile et le secret pour créer une signature unique.

112
00:05:40,650 --> 00:05:43,200
‫Donc seules ces données plus le

113
00:05:43,200 --> 00:05:46,160
‫secret peuvent créer cette signature, d'accord ?

114
00:05:46,160 --> 00:05:49,200
‫Ensuite, avec l'en-tête et la charge

115
00:05:49,200 --> 00:05:52,310
‫utile, ces signatures forment le JWT, qui

116
00:05:52,310 --> 00:05:55,190
‫est ensuite envoyé au client.

117
00:05:55,190 --> 00:05:58,320
‫Maintenant, comme je l'ai mentionné brièvement, dès la première

118
00:05:58,320 --> 00:06:02,000
‫diapositive, une fois que le serveur reçoit un JWT pour autoriser

119
00:06:02,000 --> 00:06:05,010
‫l'accès à une route protégée, il doit le vérifier

120
00:06:05,010 --> 00:06:07,730
‫afin de déterminer si l'utilisateur est vraiment celui

121
00:06:07,730 --> 00:06:10,120
‫qu'il prétend être, n'est-ce pas ?

122
00:06:10,120 --> 00:06:13,890
‫En d'autres termes, il vérifiera si personne n'a modifié l'en-tête et

123
00:06:13,890 --> 00:06:16,580
‫les données de charge utile du jeton.

124
00:06:16,580 --> 00:06:20,030
‫Encore une fois, cette étape de vérification vérifiera si

125
00:06:20,030 --> 00:06:23,350
‫aucun tiers n'a réellement modifié l'en-tête ou la

126
00:06:23,350 --> 00:06:26,280
‫charge utile du jeton Web Json.

127
00:06:26,280 --> 00:06:29,650
‫Alors, comment cette vérification fonctionne-t-elle réellement ?

128
00:06:29,650 --> 00:06:32,560
‫Eh bien, c'est en fait assez simple.

129
00:06:32,560 --> 00:06:35,410
‫Ainsi, une fois le JWT reçu, la

130
00:06:35,410 --> 00:06:38,920
‫vérification prendra son en-tête et sa charge utile

131
00:06:38,920 --> 00:06:41,540
‫et, avec le secret toujours

132
00:06:41,540 --> 00:06:45,440
‫enregistré sur le serveur, créera essentiellement une signature de test.

133
00:06:45,440 --> 00:06:48,390
‫Mais la signature originale qui a été générée

134
00:06:48,390 --> 00:06:53,390
‫lors de la création du JWT est toujours dans le jeton, n'est-ce pas ?

135
00:06:53,930 --> 00:06:56,550
‫Et c'est la clé de cette vérification.

136
00:06:56,550 --> 00:06:59,180
‫Car il ne nous reste plus

137
00:06:59,180 --> 00:07:02,590
‫qu'à comparer la signature de test avec la signature d'origine.

138
00:07:02,590 --> 00:07:05,050
‫Et si la signature de test est

139
00:07:05,050 --> 00:07:08,460
‫la même que la signature d'origine, cela signifie que la charge

140
00:07:08,460 --> 00:07:11,760
‫utile et l'en-tête n'ont pas été modifiés, n'est-ce pas ?

141
00:07:11,760 --> 00:07:13,690
‫Car s'ils avaient été

142
00:07:13,690 --> 00:07:16,720
‫modifiés, la signature de test devrait être différente.

143
00:07:16,720 --> 00:07:19,600
‫Donc dans ce cas où il n'y a

144
00:07:19,600 --> 00:07:22,990
‫pas eu d'altération des données, on peut alors authentifier l'utilisateur.

145
00:07:22,990 --> 00:07:24,940
‫Et bien sûr, si les

146
00:07:24,940 --> 00:07:27,520
‫deux signatures sont réellement différentes, eh bien, cela

147
00:07:27,520 --> 00:07:29,870
‫signifie que quelqu'un a falsifié les données.

148
00:07:29,870 --> 00:07:32,780
‫Habituellement en essayant de changer la charge utile.

149
00:07:32,780 --> 00:07:35,470
‫Mais ce tiers manipulant la charge utile

150
00:07:35,470 --> 00:07:38,750
‫n'a bien sûr pas accès au secret, il ne

151
00:07:38,750 --> 00:07:41,370
‫peut donc pas signer le JWT.

152
00:07:41,370 --> 00:07:44,320
‫Ainsi, la signature originale ne correspondra jamais

153
00:07:44,320 --> 00:07:46,050
‫aux données manipulées.

154
00:07:46,050 --> 00:07:49,160
‫Et par conséquent, la vérification échouera toujours

155
00:07:49,160 --> 00:07:50,700
‫dans ce cas.

156
00:07:50,700 --> 00:07:53,850
‫Et c'est la clé pour faire fonctionner tout ce système.

157
00:07:53,850 --> 00:07:57,190
‫C'est la magie qui rend JWT si

158
00:07:57,190 --> 00:07:59,790
‫simple, mais aussi extrêmement puissant.

159
00:07:59,790 --> 00:08:01,560
‫Alors permettez-moi de le résumer à nouveau.

160
00:08:01,560 --> 00:08:04,830
‫Sans le secret, personne ne pourra manipuler les données

161
00:08:04,830 --> 00:08:07,920
‫JWT car ils ne peuvent pas créer de

162
00:08:07,920 --> 00:08:10,960
‫signature valide pour les nouvelles données.

163
00:08:10,960 --> 00:08:13,570
‫Je veux dire qu'ils pourraient bien sûr

164
00:08:13,570 --> 00:08:16,870
‫manipuler les données, mais cela échouera toujours à l'étape de vérification.

165
00:08:16,870 --> 00:08:19,900
‫Maintenant, ne vous inquiétez pas, nous n'allons pas

166
00:08:19,900 --> 00:08:22,660
‫réellement implémenter ces algorithmes JWT par nous-mêmes.

167
00:08:22,660 --> 00:08:24,830
‫Ils sont très complexes et nous

168
00:08:24,830 --> 00:08:27,060
‫n'allons pas réinventer la roue ici, d'accord ?

169
00:08:27,060 --> 00:08:29,910
‫Mais il est toujours très important de comprendre comment

170
00:08:29,910 --> 00:08:32,110
‫tout ce processus fonctionne en coulisse.

171
00:08:32,110 --> 00:08:35,570
‫Et j'espère que cette conférence a fait exactement cela pour vous.

172
00:08:35,570 --> 00:08:38,370
‫Mais maintenant, passons à la prochaine conférence pour réellement

173
00:08:38,370 --> 00:08:40,433
‫commencer à utiliser tout cela.