1
00:00:00,000 --> 00:00:04,869
[MUSIQUE]

2
00:00:04,869 --> 00:00:06,266
Dans les leçons précédentes,

3
00:00:06,266 --> 00:00:10,110
nous avons vu plusieurs types de systèmes d'authentification différents.

4
00:00:10,110 --> 00:00:14,910
Nous avons commencé par l'authentification de base, puis nous avons examiné comment nous pouvons utiliser les cookies pour

5
00:00:14,910 --> 00:00:18,290
effectuer l'authentification, et même les cookies signés, et

6
00:00:18,290 --> 00:00:22,090
par la suite, nous avons examiné l'authentification basée sur la session.

7
00:00:22,090 --> 00:00:27,070
Où le serveur garde une trace des informations sur chaque client,

8
00:00:27,070 --> 00:00:30,680
puis le cookie sera utilisé comme un moyen d'indexation dans la

9
00:00:30,680 --> 00:00:35,720
base de données côté serveur pour extraire des informations supplémentaires, pour valider l'utilisateur.

10
00:00:35,720 --> 00:00:41,160
Maintenant, les authentifications basées sur les cookies et les sessions ne sont pas évolutives,

11
00:00:41,160 --> 00:00:47,300
car le serveur doit garder une trace de tous les utilisateurs différents.

12
00:00:48,820 --> 00:00:53,120
Même si, cela est fait en dehors du protocole HTTP lui-même,

13
00:00:53,120 --> 00:00:56,160
mais le fait que vous devez garder une trace

14
00:00:56,160 --> 00:01:00,660
de toutes les informations de section du site du serveur, le rend pas très évolutif.

15
00:01:00,660 --> 00:01:04,510
C' est donc là que l'authentification basée sur des jetons

16
00:01:04,510 --> 00:01:06,570
s'est révélée très utile.

17
00:01:06,570 --> 00:01:11,260
nous allons examiner l'authentification de base de jetons un peu plus en détail dans cette conférence et

18
00:01:11,260 --> 00:01:12,830
l'exercice qui suit.

19
00:01:14,680 --> 00:01:18,880
Encore une fois, examiner rapidement les cookies et l'authentification basée sur la session.

20
00:01:18,880 --> 00:01:20,580
Avec l'authentification basée

21
00:01:20,580 --> 00:01:25,240
sur les cookies, nous remarquons que les cookies sont stockés du côté client, et les cookies sont inclus

22
00:01:25,240 --> 00:01:29,510
dans chaque message de demande sortante, où, le serveur est rappelé à

23
00:01:29,510 --> 00:01:35,050
ce client spécifique, en extrayant des informations à partir du cookie. Le

24
00:01:35,050 --> 00:01:40,550
cookie peut être utilisé avec des sessions, dans lesquelles les cookies stockent l'ID de session,

25
00:01:40,550 --> 00:01:44,650
puis lorsque le serveur reçoit la requête entrante du cookie,

26
00:01:44,650 --> 00:01:49,770
il extrait l'ID de session et l'utilise comme index dans le

27
00:01:49,770 --> 00:01:55,210
magasin de session côté serveur pour récupérer les informations de session pour le client particulier.

28
00:01:55,210 --> 00:01:56,840
Maintenant, cette approche, comme je l'ai dit,

29
00:01:56,840 --> 00:02:01,234
n'est pas très évolutive car si vous avez des milliers de sessions, le serveur doit

30
00:02:01,234 --> 00:02:04,980
garder une trace de toutes ces milliers de sessions côté serveur.

31
00:02:04,980 --> 00:02:10,820
Même si cela est fait indépendamment de HTTP dans un magasin,

32
00:02:10,820 --> 00:02:13,770
soit un magasin de fichiers ou une base de données.

33
00:02:13,770 --> 00:02:14,610
Mais encore,

34
00:02:14,610 --> 00:02:19,520
le fait que vous avez besoin de suivre toutes ces informations rend ces informations non évolutives.

35
00:02:19,520 --> 00:02:23,960
Donc, encore une fois, pour vous rappeler une fois,

36
00:02:23,960 --> 00:02:27,201
pourquoi parlons-nous d'authentification basée sur des jetons ?

37
00:02:27,201 --> 00:02:32,260
L' authentification basée sur la session, comme nous l'avons vu précédemment, fonctionne parfaitement bien pour les

38
00:02:32,260 --> 00:02:39,910
applications Web et peut facilement prendre en charge l'authentification des utilisateurs.

39
00:02:39,910 --> 00:02:43,660
Mais alors, l'authentification basée sur la session, alors que c'est le principe des

40
00:02:43,660 --> 00:02:48,280
serveurs sans état et conduit également à des problèmes d'évolutivité.

41
00:02:48,280 --> 00:02:52,727
Le deuxième problème est que les applications mobiles ne

42
00:02:52,727 --> 00:02:58,090
gèrent pas très bien les authentifications basées sur une session.

43
00:02:58,090 --> 00:03:01,742
De même, les applications mobiles ont du mal à traiter les cookies.

44
00:03:01,742 --> 00:03:08,048
Ainsi, dans de telles circonstances où votre serveur sert des données à la

45
00:03:08,048 --> 00:03:13,610
fois pour une application Web, ainsi qu'une application mobile.

46
00:03:13,610 --> 00:03:19,275
Ensuite, l'authentification basée sur la session ne sera pas très utile, et

47
00:03:19,275 --> 00:03:25,139
c'est là que l'authentification basée sur les jetons devient beaucoup plus facile à utiliser.

48
00:03:25,139 --> 00:03:29,369
Dans une authentification basée sur un jeton comme nom en place,

49
00:03:29,369 --> 00:03:34,589
le serveur émettra un jeton à un utilisateur validé, et toutes les

50
00:03:34,589 --> 00:03:40,803
demandes suivantes venant du côté client, porteront le jeton dans la requête elle-même.

51
00:03:40,803 --> 00:03:48,992
Soit sous la forme d'un en-tête de requête, soit dans le corps du message de requête.

52
00:03:48,992 --> 00:03:53,410
De plus, l'authentification basée sur des jetons nous aide également à

53
00:03:53,410 --> 00:03:57,965
traiter ce que l'on appelle des problèmes CORS ou CSRF.

54
00:03:57,965 --> 00:04:00,480
Problèmes de partage de ressources d'origine croisée et ainsi de suite

55
00:04:00,480 --> 00:04:04,360
, je vais parler brièvement du coût dans le module suivant.

56
00:04:04,360 --> 00:04:07,540
Mais pour le moment, l'authentification basée sur des jetons résout certains

57
00:04:07,540 --> 00:04:13,430
des problèmes qui se posent avec les voitures et les problèmes liés à la falsification des requêtes intersites.

58
00:04:13,430 --> 00:04:17,680
Non seulement cela, l'authentification basée sur des jetons est beaucoup plus facile pour

59
00:04:17,680 --> 00:04:21,700
une application de partager son authentification avec une autre application.

60
00:04:21,700 --> 00:04:24,610
Bien sûr, tout cela est fait de manière sécurisée.

61
00:04:24,610 --> 00:04:28,867
Mais, avec l'authentification basée sur la session, ce n'est pas simple.

62
00:04:28,867 --> 00:04:32,272
Comment fonctionne l'authentification basée sur les jetons ?

63
00:04:32,272 --> 00:04:34,260
Dans l'authentification basée sur

64
00:04:34,260 --> 00:04:40,020
des jetons, l'utilisateur doit d'abord se valider du côté serveur.

65
00:04:40,020 --> 00:04:44,040
Maintenant, cette validation pourrait prendre les formes que nous avons vues plus tôt.

66
00:04:44,040 --> 00:04:48,519
Nous pouvons donc utiliser une validation locale en utilisant le nom d'utilisateur et le mot de passe.

67
00:04:48,519 --> 00:04:53,111
Ou, nous pouvons même utiliser la validation par des tiers en utilisant

68
00:04:53,111 --> 00:04:58,267
des technologies comme, oauth ou oauth 2.0 ou open ID.

69
00:04:58,267 --> 00:05:03,700
Nous allons parler brièvement de oauth et oauth 2.0 dans le prochain module.

70
00:05:03,700 --> 00:05:08,790
Mais, quelle que soit la manière dont l'utilisateur s'authentifie, une fois l'utilisateur

71
00:05:08,790 --> 00:05:14,370
authentifié, juste après, votre serveur peut simplement émettre un jeton à l'utilisateur.

72
00:05:14,370 --> 00:05:18,790
Et toute communication ultérieure entre l'utilisateur et

73
00:05:18,790 --> 00:05:23,658
le serveur, peut être fait simplement en utilisant ce jeton.

74
00:05:23,658 --> 00:05:29,240
JSON Web Token dont nous parlerons, est un tel

75
00:05:29,240 --> 00:05:35,465
schéma d'authentification basé sur des jetons, et là serveur quand il crée ce jeton, il va créer un jeton signé.

76
00:05:35,465 --> 00:05:40,315
Utilisation d'un secret sur le site du serveur que seul le serveur connaît.

77
00:05:40,315 --> 00:05:43,965
Ainsi, même si un tiers entre et et

78
00:05:43,965 --> 00:05:49,185
tente de manipuler le jeton, même s'il capture le jeton et

79
00:05:49,185 --> 00:05:53,045
essaie de le manipuler, le jeton deviendra invalide.

80
00:05:53,045 --> 00:05:57,201
Et donc, cette façon de protéger l'utilisateur est

81
00:05:57,201 --> 00:06:02,250
facilement faisable, toutes les demandes ultérieures

82
00:06:02,250 --> 00:06:07,430
du côté client devraient porter le jeton dans la requête,

83
00:06:07,430 --> 00:06:11,870
soit, comme je l'ai dit, dans l'en-tête ou dans le corps du message de requête.

84
00:06:11,870 --> 00:06:16,120
Ainsi, lorsque le serveur reçoit ce jeton, le serveur vérifiera le jeton,

85
00:06:16,120 --> 00:06:20,810
pour s'assurer qu'il s'agit d'un jeton valide, puis s'il s'agit d'un jeton valide,

86
00:06:20,810 --> 00:06:25,430
le serveur répondra alors à la demande entrante.

87
00:06:25,430 --> 00:06:31,210
Comme je l'ai mentionné, JSON Web Tokens est un tel schéma d'authentification basé sur des jetons.

88
00:06:31,210 --> 00:06:35,838
JSON Web Token, est un moyen très simple d'encoder des

89
00:06:35,838 --> 00:06:41,174
informations dans un jeton puis de les transmettre au site client.

90
00:06:41,174 --> 00:06:45,702
JSON Web Token lui-même est basé sur des normes,

91
00:06:45,702 --> 00:06:49,670
ceci est basé sur l'IETF RFC 7519.

92
00:06:49,670 --> 00:06:53,499
IETF ici, signifie l'Internet Engineering Task Force.

93
00:06:53,499 --> 00:07:00,011
L' organisation qui commande tout sur le fonctionnement de l'Internet,

94
00:07:00,011 --> 00:07:06,427
et traite des protocoles et des politiques, liés à Internet.

95
00:07:06,427 --> 00:07:10,391
Le RFC, signifie le document de normes,

96
00:07:10,391 --> 00:07:15,270
en termes IETF, RFC signifie Request for Comments.

97
00:07:15,270 --> 00:07:18,650
Et chacun de ces documents de normes porte un numéro.

98
00:07:18,650 --> 00:07:23,560
7519 dans ce cas fait référence au document,

99
00:07:23,560 --> 00:07:27,250
le document standard lié à JSON Web Token.

100
00:07:27,250 --> 00:07:31,420
Le jeton Web JSON lui-même est un jeton autonome, il transporte toutes

101
00:07:31,420 --> 00:07:37,250
les informations en lui-même, ce qui est nécessaire pour identifier l'utilisateur.

102
00:07:37,250 --> 00:07:43,080
Non seulement cela, un jeton Web JSON peut être partagé entre deux applications.

103
00:07:43,080 --> 00:07:46,930
Ainsi, par exemple, une application lorsqu'elle s'authentifie et obtient ensuite

104
00:07:46,930 --> 00:07:51,760
un jeton Web JSON, peut transmettre ce jeton Web JSON à et dans cette application,

105
00:07:51,760 --> 00:07:56,950
qu'elle est prête à autoriser à accéder au serveur en son nom.

106
00:07:56,950 --> 00:08:00,200
Ce partage du jeton se fait d'une manière très sécurisée,

107
00:08:00,200 --> 00:08:03,460
alors ne vous inquiétez pas trop de sécurité là-dedans.

108
00:08:03,460 --> 00:08:04,990
Ce n'est pas d'une manière sécurisée,

109
00:08:04,990 --> 00:08:09,090
où par le partage du jeton entre une application à une autre.

110
00:08:09,090 --> 00:08:13,250
Ainsi, l'autorisation est transférée vers une deuxième application, et

111
00:08:13,250 --> 00:08:17,740
la seconde application peut autoriser au nom de la première application,

112
00:08:17,740 --> 00:08:18,990
à communiquer avec le serveur.

113
00:08:20,200 --> 00:08:24,200
Ceci est faisable avec des jetons.

114
00:08:24,200 --> 00:08:28,710
Maintenant, bien sûr, l'ingénieur en vous se demandera évidemment ce qu'il y a exactement

115
00:08:28,710 --> 00:08:32,690
à l'intérieur d'un jeton Web JSON, et comment est-il utile ?

116
00:08:32,690 --> 00:08:39,120
Un jeton Web JSON, comme je l'ai dit, est encodé dans une longue chaîne et

117
00:08:39,120 --> 00:08:43,530
cette chaîne elle-même peut être interprétée comme composée de trois parties.

118
00:08:43,530 --> 00:08:49,470
La chaîne elle-même peut, ou la chaîne codée elle-même contient trois parties,

119
00:08:49,470 --> 00:08:52,896
l'en-tête, la charge utile et la signature.

120
00:08:52,896 --> 00:08:59,070
Cela contient suffisamment d'informations sur la façon dont ce jeton est codé.

121
00:08:59,070 --> 00:09:03,780
L' en-tête lui-même contient l'algorithme spécifique utilisé pour

122
00:09:03,780 --> 00:09:08,460
coder ce jeton Web JSON, et le type du jeton lui-même.

123
00:09:08,460 --> 00:09:16,280
L' algorithme dans ce cas, serait HS256 qui est un schéma d'encodage 256 bits,

124
00:09:16,280 --> 00:09:21,140
qui est utilisé pour hacher les informations à l'intérieur du jeton.

125
00:09:21,140 --> 00:09:24,350
Et dans ce cas, il se trouve que c'est le jeton Web JSON, et donc

126
00:09:24,350 --> 00:09:27,870
le champ type sera défini sur JWT.

127
00:09:27,870 --> 00:09:33,210
Et c'est donc l'information qui est stockée dans l'en-tête de JSON Web Token.

128
00:09:33,210 --> 00:09:38,800
La charge utile elle-même, contient des informations qui vous aident à identifier l'utilisateur.

129
00:09:38,800 --> 00:09:41,440
Dans l'exercice que nous allons faire,

130
00:09:41,440 --> 00:09:46,730
la charge utile horaire ne porte que l'ID de l'utilisateur à l'intérieur de la charge utile.

131
00:09:46,730 --> 00:09:48,720
Aucune autre information n'est nécessaire.

132
00:09:48,720 --> 00:09:51,690
Cet ID peut être utilisé côté serveur,

133
00:09:51,690 --> 00:09:58,350
pour indexer dans la base de données Mongo pour récupérer les informations complètes de l'utilisateur si nécessaire.

134
00:09:58,350 --> 00:10:02,050
Donc, vous verrez que nous allons encoder l'ID

135
00:10:02,050 --> 00:10:05,020
puis le stocker dans la charge utile de ce message.

136
00:10:05,020 --> 00:10:09,470
Vous pouvez stocker des informations supplémentaires dans la charge utile du message si vous le souhaitez.

137
00:10:09,470 --> 00:10:11,410
Mais plus vous y stockez d'informations,

138
00:10:11,410 --> 00:10:15,720
plus le jeton Web JSON correspondant va à moi.

139
00:10:15,720 --> 00:10:20,010
Donc, essayez de limiter la quantité d'informations que vous avez stockées dans la charge utile

140
00:10:20,010 --> 00:10:22,155
du jeton Web JSON.

141
00:10:22,155 --> 00:10:27,545
Comme nous le verrons dans l'exercice, nous avons un module de nœud qui nous

142
00:10:27,545 --> 00:10:30,875
permet d'encoder et de créer un jeton Web JSON,

143
00:10:30,875 --> 00:10:34,395
basé sur les informations que nous voulons mettre dans la charge utile.

144
00:10:34,395 --> 00:10:38,735
Maintenant, lorsque vous créez un jeton Web JSON, vous fournissez également une signature.

145
00:10:38,735 --> 00:10:44,929
Une clé secrète du côté serveur qui est utilisée pour coder ce jeton Web JSON,

146
00:10:44,929 --> 00:10:51,044
et ce secret est également inclus dans la partie signature du jeton Web JSON.

147
00:10:51,044 --> 00:10:55,232
La signature elle-même est incluse de telle sorte qu'il y ait

148
00:10:55,232 --> 00:10:58,797
une base avant l'en-tête codé et la charge utile,

149
00:10:58,797 --> 00:11:04,750
qui est ensuite encodé en utilisant le secret spécifique utilisé par le serveur.

150
00:11:04,750 --> 00:11:08,644
Et cela encodé dans, comme je l'ai dit le HMAC,

151
00:11:08,644 --> 00:11:14,144
que nous avons fait référence dans l'une des leçons précédentes et

152
00:11:14,144 --> 00:11:20,922
en utilisant le hachage 256 bits, et qui est inclus dans la signature.

153
00:11:20,922 --> 00:11:25,118
Ainsi, lorsque ce jeton Web JSON est reçu côté serveur, et

154
00:11:25,118 --> 00:11:30,094
lorsque le serveur décode ce jeton, le serveur est capable de

155
00:11:30,094 --> 00:11:34,525
vérifier que ce jeton Web JSON n'a pas été altéré par personne,

156
00:11:34,525 --> 00:11:39,460
alors que le jeton est passé entre le client et le site du serveur.

157
00:11:39,460 --> 00:11:43,020
Donc, si vous savez quelque chose sur la sécurité, et les intrus,

158
00:11:43,020 --> 00:11:47,670
et ainsi de suite, vous comprenez pourquoi il est important d'encoder le jeton, et de

159
00:11:47,670 --> 00:11:53,250
vérifier l'authenticité du jeton sur le site du serveur.

160
00:11:53,250 --> 00:11:58,640
Comme je l'ai mentionné, si vous avez besoin de traiter les jetons Web JSON dans votre application de nœud.

161
00:11:58,640 --> 00:12:02,810
Il existe un module de nœud spécifique appelé le module de nœud jsonwebtoken.

162
00:12:02,810 --> 00:12:07,830
Ce module de nœud implémente les normes liées au jeton Web JSON, et

163
00:12:07,830 --> 00:12:10,640
il peut être inclus dans votre application de nœud.

164
00:12:10,640 --> 00:12:15,190
Ce module lui-même, fournit une méthode appelée signe qui vous permet de signer et d'

165
00:12:15,190 --> 00:12:18,910
émettre le jeton au client à partir du côté serveur.

166
00:12:18,910 --> 00:12:21,820
Il contient également une méthode de vérification.

167
00:12:21,820 --> 00:12:27,040
Qui peut être utilisé pour vérifier l'authenticité ou

168
00:12:27,040 --> 00:12:33,380
pour assurer l'authenticité du jeton Web JSON entrant,

169
00:12:33,380 --> 00:12:38,620
donc nous allons utiliser le module de jeton Web JSON, dans notre exercice.

170
00:12:38,620 --> 00:12:42,010
Avec le module JSON Web Token,

171
00:12:42,010 --> 00:12:47,450
nous avons également utilisé le module Passport-JWT, module nœud.

172
00:12:47,450 --> 00:12:54,547
Ce qui fournit les stratégies basées sur JWT pour notre module d'authentification de passeport.

173
00:12:54,547 --> 00:12:59,441
Cela fournit donc une stratégie de passeport pour l'authentification à l'aide du jeton Web JSON.

174
00:12:59,441 --> 00:13:06,153
Cela vous permet donc d'authentifier le point de terminaison RESTful en utilisant le JWT comme méthode de

175
00:13:06,153 --> 00:13:12,240
validation dong, sans nécessiter que le serveur utilise des sessions.

176
00:13:12,240 --> 00:13:17,300
Maintenant, le module de passeport JWT

177
00:13:17,300 --> 00:13:21,710
prend en charge une méthode permettant même d'extraire le jeton JWT

178
00:13:21,710 --> 00:13:26,970
du message de demande entrante, puis même de vérifier le jeton en votre nom.

179
00:13:26,970 --> 00:13:31,470
Le stagiaire du module Passport-JWT utilise le module JSON Web Token pour

180
00:13:31,470 --> 00:13:34,550
effectuer la vérification de ce jeton Web JSON.

181
00:13:34,550 --> 00:13:40,300
Le jeton lui-même peut être porté dans l'en-tête de la requête entrante,

182
00:13:40,300 --> 00:13:44,350
dans l'en-tête, même dans l'en-tête d'authentification de la requête entrante, ce

183
00:13:44,350 --> 00:13:46,940
qui est ce que nous allons faire dans l'exercice.

184
00:13:46,940 --> 00:13:51,420
Le jeton peut également être transporté dans le corps de la demande entrante, auquel cas,

185
00:13:51,420 --> 00:13:54,610
nous devons extraire le jeton du corps de la demande entrante

186
00:13:54,610 --> 00:13:56,352
, puis en faire usage.

187
00:13:56,352 --> 00:14:01,170
Le module Passport-JWT prend également en charge cela si vous choisissez de l'

188
00:14:01,170 --> 00:14:06,580
utiliser comme moyen de transmettre le jeton du client au site serveur.

189
00:14:06,580 --> 00:14:11,600
Le jeton Web JSON, peut également être inclus dans les paramètres de requête URL si vous le

190
00:14:11,600 --> 00:14:16,440
choisissez, et peut être extrait de là b Passport-JWT et

191
00:14:16,440 --> 00:14:18,370
utilisé pour l'authentification.

192
00:14:18,370 --> 00:14:22,783
Maintenant, avec cette compréhension rapide des jetons Web JSON et de

193
00:14:22,783 --> 00:14:27,915
leur utilité, nous allons passer à l'exercice où nous allons utiliser

194
00:14:27,915 --> 00:14:33,230
le module Passport-JWT, avec le module JSON Web Token,

195
00:14:33,230 --> 00:14:38,211
et configurer notre serveur d'API Express Rest pour utiliser JSON Web Tokens.

196
00:14:38,211 --> 00:14:41,589
[ MUSIQUE]