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

2
00:00:04,869 --> 00:00:06,266
Nelle lezioni precedenti,

3
00:00:06,266 --> 00:00:10,110
abbiamo visto diversi tipi di schemi di autenticazione.

4
00:00:10,110 --> 00:00:14,910
Abbiamo iniziato con l'autenticazione di base, poi abbiamo esaminato come possiamo usare i cookie per

5
00:00:14,910 --> 00:00:18,290
fare l'autenticazione, e anche i cookie firmati, e in

6
00:00:18,290 --> 00:00:22,090
seguito, abbiamo esaminato l'autenticazione basata su sessione.

7
00:00:22,090 --> 00:00:27,070
Dove il server tiene traccia delle informazioni su ciascun client, e

8
00:00:27,070 --> 00:00:30,680
quindi il cookie verrà utilizzato come un modo di indicizzare nel

9
00:00:30,680 --> 00:00:35,720
database lato server per estrarre informazioni aggiuntive, per convalidare l'utente.

10
00:00:35,720 --> 00:00:41,160
Ora, i cookie e le autenticazioni basate su sessione non sono scalabili,

11
00:00:41,160 --> 00:00:47,300
perché lì server deve tenere traccia di tutti i diversi utenti.

12
00:00:48,820 --> 00:00:53,120
Anche se, questo viene fatto al di fuori del protocollo HTTP stesso, ma

13
00:00:53,120 --> 00:00:56,160
ancora il fatto che è necessario tenere traccia

14
00:00:56,160 --> 00:01:00,660
di tutte le informazioni della sezione del sito del server, lo rende non molto scalabile.

15
00:01:00,660 --> 00:01:04,510
Quindi questo è dove l'autenticazione basata su token

16
00:01:04,510 --> 00:01:06,570
si è dimostrata molto utile.

17
00:01:06,570 --> 00:01:11,260
vedremo l'autenticazione token base un po 'più dettagliata in questa lezione ed

18
00:01:11,260 --> 00:01:12,830
esercizio che segue.

19
00:01:14,680 --> 00:01:18,880
Ancora una volta, rivedere rapidamente i cookie e l'autenticazione basata sulla sessione.

20
00:01:18,880 --> 00:01:20,580
Con l'autenticazione basata sui

21
00:01:20,580 --> 00:01:25,240
cookie, notiamo che i cookie sono memorizzati sul lato client, e i cookie sono inclusi

22
00:01:25,240 --> 00:01:29,510
in ogni messaggio di richiesta in uscita per cui, il server viene ricordato su

23
00:01:29,510 --> 00:01:35,050
quel client specifico, estraendo informazioni dal cookie. Il

24
00:01:35,050 --> 00:01:40,550
cookie può essere utilizzato insieme alle sessioni, per cui i cookie memorizzano l'ID di sessione,

25
00:01:40,550 --> 00:01:44,650
e quindi quando il server riceve la richiesta in arrivo dal cookie,

26
00:01:44,650 --> 00:01:49,770
estrae l'ID di sessione e lo utilizza come indice nell'

27
00:01:49,770 --> 00:01:55,210
archivio sessione lato server per recuperare le informazioni di sessione per il cliente particolare.

28
00:01:55,210 --> 00:01:56,840
Ora, questo approccio, come ho detto,

29
00:01:56,840 --> 00:02:01,234
non è molto scalabile perché se hai migliaia di sessioni, il server deve

30
00:02:01,234 --> 00:02:04,980
tenere traccia di tutte queste migliaia di sessioni sul lato server.

31
00:02:04,980 --> 00:02:10,820
Anche se è fatto indipendentemente da HTTP in un negozio,

32
00:02:10,820 --> 00:02:13,770
un archivio di file o un database.

33
00:02:13,770 --> 00:02:14,610
Tuttavia,

34
00:02:14,610 --> 00:02:19,520
il fatto che sia necessario tenere traccia di tutte queste informazioni non le rende scalabili.

35
00:02:19,520 --> 00:02:23,960
Quindi, ancora una volta, per ricordarti ancora una volta,

36
00:02:23,960 --> 00:02:27,201
perché parliamo di autenticazione basata su token?

37
00:02:27,201 --> 00:02:32,260
L' autenticazione basata su sessione, come abbiamo visto in precedenza, funziona perfettamente per

38
00:02:32,260 --> 00:02:39,910
le applicazioni web e può facilmente prendersi cura dell'autenticazione utente.

39
00:02:39,910 --> 00:02:43,660
Ma poi, l'autenticazione basata su sessione, mentre è il principio dei

40
00:02:43,660 --> 00:02:48,280
server stateless e porta anche a problemi di scalabilità.

41
00:02:48,280 --> 00:02:52,727
Il secondo problema è che le applicazioni mobili non

42
00:02:52,727 --> 00:02:58,090
gestiscono molto bene le autenticazioni basate su sessione.

43
00:02:58,090 --> 00:03:01,742
Allo stesso modo, le applicazioni mobili hanno difficoltà a gestire i cookie.

44
00:03:01,742 --> 00:03:08,048
Quindi, in tali circostanze in cui il server sta fornendo dati

45
00:03:08,048 --> 00:03:13,610
sia per un'applicazione web, sia per un'app mobile.

46
00:03:13,610 --> 00:03:19,275
Quindi, l'autenticazione basata sulla sessione non sarà molto utile, ed

47
00:03:19,275 --> 00:03:25,139
è qui che l'autenticazione basata su token diventa molto più facile da usare.

48
00:03:25,139 --> 00:03:29,369
In un'autenticazione basata su token come nome in atto,

49
00:03:29,369 --> 00:03:34,589
il server emetterà un token a un utente convalidato, e tutte le

50
00:03:34,589 --> 00:03:40,803
richieste successive provenienti dal lato client, porterà il token nella richiesta stessa.

51
00:03:40,803 --> 00:03:48,992
Nella forma di un'intestazione di richiesta o nel corpo del messaggio di richiesta.

52
00:03:48,992 --> 00:03:53,410
Inoltre, l'autenticazione basata su token ci aiuta anche

53
00:03:53,410 --> 00:03:57,965
a gestire quelli che sono chiamati problemi CORS o CSRF.

54
00:03:57,965 --> 00:04:00,480
Problemi di condivisione delle risorse di origine

55
00:04:00,480 --> 00:04:04,360
incrociata e così via, parlerò brevemente del costo nel prossimo modulo.

56
00:04:04,360 --> 00:04:07,540
Ma per il momento, l'autenticazione basata su token risolve alcuni dei

57
00:04:07,540 --> 00:04:13,430
problemi che si trovano con le auto e i problemi correlati alla contraffazione di richieste cross-site.

58
00:04:13,430 --> 00:04:17,680
Non solo, l'autenticazione basata su token è molto più facile per

59
00:04:17,680 --> 00:04:21,700
un'applicazione condividere la propria autenticazione con un'altra applicazione.

60
00:04:21,700 --> 00:04:24,610
Naturalmente, tutto questo è fatto in modo sicuro.

61
00:04:24,610 --> 00:04:28,867
Ma, con l'autenticazione basata su sessione, non è semplice.

62
00:04:28,867 --> 00:04:32,272
Come funziona l'autenticazione basata su token?

63
00:04:32,272 --> 00:04:34,260
Nell' autenticazione basata su token,

64
00:04:34,260 --> 00:04:40,020
l'utente deve prima convalidare se stesso sul lato server.

65
00:04:40,020 --> 00:04:44,040
Ora, questa convalida potrebbe assumere le forme che abbiamo visto prima.

66
00:04:44,040 --> 00:04:48,519
Quindi possiamo usare una convalida locale utilizzando nome utente e password.

67
00:04:48,519 --> 00:04:53,111
Oppure, possiamo anche utilizzare la convalida di terze parti utilizzando

68
00:04:53,111 --> 00:04:58,267
tecnologie come, oauth o oauth 2.0 o open ID.

69
00:04:58,267 --> 00:05:03,700
Parleremo brevemente di oauth e oauth 2.0 nel prossimo modulo.

70
00:05:03,700 --> 00:05:08,790
Tuttavia, indipendentemente dal modo in cui l'utente si autentica, una volta che l'utente

71
00:05:08,790 --> 00:05:14,370
è autenticato, subito dopo, il server può semplicemente emettere un token all'utente.

72
00:05:14,370 --> 00:05:18,790
E tutte le successive comunicazioni tra l'utente e

73
00:05:18,790 --> 00:05:23,658
il server, possono essere fatte semplicemente usando questo token.

74
00:05:23,658 --> 00:05:29,240
JSON Web Token di cui parleremo, è uno di questi

75
00:05:29,240 --> 00:05:35,465
schema di autenticazione basato su token, e lì server quando crea questo token, creerà un token firmato.

76
00:05:35,465 --> 00:05:40,315
Utilizzando un segreto sul sito server che solo il server conosce.

77
00:05:40,315 --> 00:05:43,965
Quindi, anche se una terza parte in avanti e tra e

78
00:05:43,965 --> 00:05:49,185
tenta di manipolare il token, anche se cattura il token e

79
00:05:49,185 --> 00:05:53,045
tenta di manipolare il token, il token diventerà non valido.

80
00:05:53,045 --> 00:05:57,201
E così, questo modo di proteggere l'utente è

81
00:05:57,201 --> 00:06:02,250
facilmente fattibile, tutte le richieste successive

82
00:06:02,250 --> 00:06:07,430
dal lato client dovrebbero portare il token nella richiesta,

83
00:06:07,430 --> 00:06:11,870
sia, come ho detto, nell'intestazione o nel corpo del messaggio di richiesta.

84
00:06:11,870 --> 00:06:16,120
Quindi, quando il server riceve questo token, il server verificherà il token,

85
00:06:16,120 --> 00:06:20,810
per assicurarsi che si tratta di un token valido, e quindi se si tratta di un token valido,

86
00:06:20,810 --> 00:06:25,430
il server risponderà alla richiesta in arrivo.

87
00:06:25,430 --> 00:06:31,210
Come ho accennato, JSON Web Tokens è uno di questi schemi di autenticazione basati su token.

88
00:06:31,210 --> 00:06:35,838
JSON Web Token, è un modo molto semplice di codificare

89
00:06:35,838 --> 00:06:41,174
le informazioni in un token e quindi passarle al sito client.

90
00:06:41,174 --> 00:06:45,702
JSON Web Token si basa su standard,

91
00:06:45,702 --> 00:06:49,670
questo è basato su IETF RFC 7519.

92
00:06:49,670 --> 00:06:53,499
IETF qui, sta per Internet Engineering Task Force.

93
00:06:53,499 --> 00:07:00,011
L' organizzazione che dà tutto su come funziona internet,

94
00:07:00,011 --> 00:07:06,427
e si occupa dei protocolli e delle politiche, relative a Internet.

95
00:07:06,427 --> 00:07:10,391
La RFC, sta per il documento standard,

96
00:07:10,391 --> 00:07:15,270
in termini IETF, RFC sta per Request for Comments.

97
00:07:15,270 --> 00:07:18,650
E ognuno di questi documenti standard porta un numero.

98
00:07:18,650 --> 00:07:23,560
7519 in questo caso si riferisce al documento,

99
00:07:23,560 --> 00:07:27,250
il documento standard relativo a JSON Web Token.

100
00:07:27,250 --> 00:07:31,420
Il token Web JSON stesso è un token autonomo, porta tutte

101
00:07:31,420 --> 00:07:37,250
le informazioni al suo interno, necessarie per identificare l'utente.

102
00:07:37,250 --> 00:07:43,080
Non solo, un token Web JSON può essere condiviso tra due applicazioni.

103
00:07:43,080 --> 00:07:46,930
Ad esempio, un'applicazione quando si autentica e poi entra in possesso di

104
00:07:46,930 --> 00:07:51,760
un token Web JSON, può passare quel token Web JSON a e in quell'applicazione,

105
00:07:51,760 --> 00:07:56,950
che è disposta ad autorizzare ad accedere al server per suo conto.

106
00:07:56,950 --> 00:08:00,200
Questa condivisione del token viene eseguita in modo molto sicuro,

107
00:08:00,200 --> 00:08:03,460
quindi non preoccuparti troppo della sicurezza lì dentro.

108
00:08:03,460 --> 00:08:04,990
Questo non è in modo sicuro,

109
00:08:04,990 --> 00:08:09,090
dove dalla condivisione del token tra un'applicazione a un'altra.

110
00:08:09,090 --> 00:08:13,250
In tal modo, l'autorizzazione viene trasferita su una seconda applicazione e

111
00:08:13,250 --> 00:08:17,740
la seconda applicazione può autorizzare per conto della prima applicazione,

112
00:08:17,740 --> 00:08:18,990
a comunicare con il server.

113
00:08:20,200 --> 00:08:24,200
Questo è fattibile con i token.

114
00:08:24,200 --> 00:08:28,710
Ora, ovviamente, l'ingegnere in te si starà chiedendo cosa sia esattamente

115
00:08:28,710 --> 00:08:32,690
all'interno di un token Web JSON e come è utile?

116
00:08:32,690 --> 00:08:39,120
Un token Web JSON, come ho detto, è codificato in una stringa lunga e

117
00:08:39,120 --> 00:08:43,530
questa stringa stessa può essere interpretata come composta da tre parti.

118
00:08:43,530 --> 00:08:49,470
La stringa stessa può, o la stringa codificata stessa contiene tre parti,

119
00:08:49,470 --> 00:08:52,896
l'intestazione, il payload e la firma.

120
00:08:52,896 --> 00:08:59,070
Questo porta abbastanza informazioni su come questo token è codificato.

121
00:08:59,070 --> 00:09:03,780
L' intestazione stessa contiene l'algoritmo specifico utilizzato per la

122
00:09:03,780 --> 00:09:08,460
codifica di questo token Web JSON e il tipo del token stesso.

123
00:09:08,460 --> 00:09:16,280
L' algoritmo in questo caso, sarebbe HS256 che è uno schema di codifica a 256 bit,

124
00:09:16,280 --> 00:09:21,140
che viene utilizzato per l'hashing delle informazioni all'interno del token.

125
00:09:21,140 --> 00:09:24,350
E in questo caso, questo sembra essere il token Web JSON, e quindi

126
00:09:24,350 --> 00:09:27,870
il campo del tipo verrà impostato su JWT.

127
00:09:27,870 --> 00:09:33,210
E così questa è l'informazione che viene memorizzata nell'intestazione di JSON Web Token.

128
00:09:33,210 --> 00:09:38,800
Il Payload stesso, porta informazioni che ti aiutano a identificare l'utente.

129
00:09:38,800 --> 00:09:41,440
Nell' esercizio che faremo,

130
00:09:41,440 --> 00:09:46,730
il payload ora porta solo l'ID dell'utente all'interno del payload.

131
00:09:46,730 --> 00:09:48,720
Non sono necessarie altre informazioni.

132
00:09:48,720 --> 00:09:51,690
Questo ID può essere utilizzato sul lato server,

133
00:09:51,690 --> 00:09:58,350
per indicizzare nel DB Mongo per recuperare le informazioni complete dell'utente, se necessario.

134
00:09:58,350 --> 00:10:02,050
Quindi, vedrai che codificheremo l'ID e

135
00:10:02,050 --> 00:10:05,020
poi lo memorizzeremo nel payload di quel messaggio.

136
00:10:05,020 --> 00:10:09,470
Se necessario, è possibile memorizzare informazioni aggiuntive nel payload del messaggio.

137
00:10:09,470 --> 00:10:11,410
Ma più informazioni memorizzate lì,

138
00:10:11,410 --> 00:10:15,720
più grande è il token Web JSON corrispondente.

139
00:10:15,720 --> 00:10:20,010
Quindi, provare a limitare la quantità di informazioni memorizzate nel payload

140
00:10:20,010 --> 00:10:22,155
del token Web JSON.

141
00:10:22,155 --> 00:10:27,545
Come vedremo nell'esercizio, abbiamo un modulo nodo che ci permette di

142
00:10:27,545 --> 00:10:30,875
codificare e creare un token Web JSON, in

143
00:10:30,875 --> 00:10:34,395
base alle informazioni che vogliamo mettere nel payload.

144
00:10:34,395 --> 00:10:38,735
Ora, quando si crea un token Web JSON, si fornisce anche una firma.

145
00:10:38,735 --> 00:10:44,929
Una chiave segreta sul lato server che viene utilizzata per la codifica di questo token Web JSON

146
00:10:44,929 --> 00:10:51,044
e tale segreto è incluso anche nella parte firma del token Web JSON.

147
00:10:51,044 --> 00:10:55,232
La firma stessa è inclusa in modo tale che vi

148
00:10:55,232 --> 00:10:58,797
sia una base prima di intestazione codificata e payload,

149
00:10:58,797 --> 00:11:04,750
che viene quindi codificato utilizzando il segreto specifico che viene utilizzato dal server.

150
00:11:04,750 --> 00:11:08,644
E questo codificato in, come ho detto l'HMAC,

151
00:11:08,644 --> 00:11:14,144
che abbiamo fatto riferimento in una delle lezioni precedenti e

152
00:11:14,144 --> 00:11:20,922
utilizzando l'hashing 256 bit, e che è incluso nella firma.

153
00:11:20,922 --> 00:11:25,118
Quindi, quando questo token Web JSON viene ricevuto sul lato server e

154
00:11:25,118 --> 00:11:30,094
quando il server decodifica questo token, il server è in grado di controllare

155
00:11:30,094 --> 00:11:34,525
incrociati per assicurarsi che questo token Web JSON non sia stato manomesso da nessuno,

156
00:11:34,525 --> 00:11:39,460
mentre il token viene passato tra il client e il sito del server.

157
00:11:39,460 --> 00:11:43,020
Quindi, se sai qualcosa sulla sicurezza,

158
00:11:43,020 --> 00:11:47,670
sugli intrusi e così via, capisci perché è importante codificare il token e

159
00:11:47,670 --> 00:11:53,250
verificare l'autenticità del token sul sito del server.

160
00:11:53,250 --> 00:11:58,640
Come ho detto, se hai bisogno di gestire i token Web JSON nell'applicazione nodo.

161
00:11:58,640 --> 00:12:02,810
Esiste un modulo nodo specifico chiamato come modulo nodo jsonwebtoken.

162
00:12:02,810 --> 00:12:07,830
Questo modulo nodo implementa gli standard correlati al token Web JSON e

163
00:12:07,830 --> 00:12:10,640
può essere incluso nell'applicazione nodo.

164
00:12:10,640 --> 00:12:15,190
Questo modulo stesso, fornisce un metodo chiamato segno che consente di firmare ed

165
00:12:15,190 --> 00:12:18,910
emettere il token al client dal lato server.

166
00:12:18,910 --> 00:12:21,820
Contiene anche un metodo di verifica.

167
00:12:21,820 --> 00:12:27,040
Che può essere utilizzato per verificare l'autenticità o

168
00:12:27,040 --> 00:12:33,380
per garantire l'autenticità del token Web JSON in entrata,

169
00:12:33,380 --> 00:12:38,620
quindi useremo il modulo token Web JSON, nel nostro esercizio.

170
00:12:38,620 --> 00:12:42,010
Insieme al modulo JSON Web Token,

171
00:12:42,010 --> 00:12:47,450
abbiamo utilizzato anche il modulo Passport-JWT, modulo nodo.

172
00:12:47,450 --> 00:12:54,547
Che fornisce le strategie basate su jwt per il nostro modulo di autenticazione del passaporto.

173
00:12:54,547 --> 00:12:59,441
Quindi questo fornisce una strategia di passaporto per l'autenticazione utilizzando JSON Web Token.

174
00:12:59,441 --> 00:13:06,153
Quindi questo consente di autenticare l'endpoint RESTful utilizzando il JWT come metodo per

175
00:13:06,153 --> 00:13:12,240
dong la convalida, senza richiedere al server di utilizzare le sessioni.

176
00:13:12,240 --> 00:13:17,300
Ora, il modulo passaporto JWT,

177
00:13:17,300 --> 00:13:21,710
supporta un metodo per estrarre anche il token JWT

178
00:13:21,710 --> 00:13:26,970
dal messaggio di richiesta in arrivo e quindi anche verificare il token per tuo conto.

179
00:13:26,970 --> 00:13:31,470
Lo stagista del modulo Passport-JWT utilizza il modulo JSON Web Token per

180
00:13:31,470 --> 00:13:34,550
eseguire la verifica di quel token Web JSON.

181
00:13:34,550 --> 00:13:40,300
Il token stesso può essere portato nell'intestazione della richiesta in arrivo,

182
00:13:40,300 --> 00:13:44,350
nell'intestazione, anche nell'intestazione di autenticazione della richiesta in arrivo,

183
00:13:44,350 --> 00:13:46,940
che è ciò che faremo nell'esercizio.

184
00:13:46,940 --> 00:13:51,420
Il token può anche essere trasportato nel corpo della richiesta in arrivo, nel qual caso,

185
00:13:51,420 --> 00:13:54,610
dobbiamo estrarre il token dal corpo della richiesta in arrivo e

186
00:13:54,610 --> 00:13:56,352
quindi utilizzarlo.

187
00:13:56,352 --> 00:14:01,170
Il modulo Passport-JWT, lo supporta anche se si sceglie di

188
00:14:01,170 --> 00:14:06,580
utilizzarlo come modo di passare il token dal client al sito server.

189
00:14:06,580 --> 00:14:11,600
Il token Web JSON, può anche essere incluso nei parametri di query URL se si

190
00:14:11,600 --> 00:14:16,440
sceglie di, e può essere estratto da lì b Passport-JWT e

191
00:14:16,440 --> 00:14:18,370
utilizzato per l'autenticazione.

192
00:14:18,370 --> 00:14:22,783
Ora, con questa rapida comprensione dei token Web JSON e di

193
00:14:22,783 --> 00:14:27,915
come sono utili, passeremo all'esercizio in cui useremo il modulo

194
00:14:27,915 --> 00:14:33,230
Passport-JWT, insieme al modulo JSON Web Token,

195
00:14:33,230 --> 00:14:38,211
e configurare il nostro server API Express Rest per utilizzare i token Web JSON.

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