1 00:00:00,930 --> 00:00:03,210 ‫Istruttore: Quindi abbiamo impostato il nostro 2 00:00:03,210 --> 00:00:06,440 ‫modello utente pronto per salvare gli utenti con password sicure. 3 00:00:06,440 --> 00:00:08,850 ‫Quindi, in seguito, implementeremo 4 00:00:08,850 --> 00:00:11,670 ‫davvero l'autenticazione e l'autorizzazione dell'utente. 5 00:00:11,670 --> 00:00:14,230 ‫Quindi, in termini semplici, l'intero flusso di 6 00:00:14,230 --> 00:00:16,530 ‫lavoro di accesso degli utenti e 7 00:00:16,530 --> 00:00:19,360 ‫consentendo loro di interagire con determinate risorse protette a 8 00:00:19,360 --> 00:00:22,163 ‫cui gli utenti non registrati non possono accedere. 9 00:00:23,100 --> 00:00:26,050 ‫Ora ci sono molti metodi di autenticazione 10 00:00:26,050 --> 00:00:29,360 ‫là fuori, ma quello che useremo è un approccio 11 00:00:29,360 --> 00:00:34,360 ‫molto moderno, semplice e sicuro chiamato Json Web Tokens o JWT in breve. 12 00:00:35,170 --> 00:00:38,100 ‫Quindi i token Web Json sono una soluzione senza 13 00:00:38,100 --> 00:00:39,500 ‫stato per l'autenticazione. 14 00:00:39,500 --> 00:00:43,410 ‫Quindi non è necessario memorizzare alcuno stato di sessione sul 15 00:00:43,410 --> 00:00:47,360 ‫server, il che ovviamente è perfetto per API riposanti come quella 16 00:00:47,360 --> 00:00:48,580 ‫che stiamo costruendo. 17 00:00:48,580 --> 00:00:53,080 ‫Perché ricorda, le API restful dovrebbero sempre essere stateless. 18 00:00:53,080 --> 00:00:56,300 ‫E l'alternativa più utilizzata all'autenticazione con JWT 19 00:00:56,300 --> 00:01:00,240 ‫è semplicemente memorizzare lo stato di accesso dell'utente sul 20 00:01:00,240 --> 00:01:02,420 ‫server utilizzando le sessioni. 21 00:01:02,420 --> 00:01:05,150 ‫Ma ovviamente non segue il principio che 22 00:01:05,150 --> 00:01:08,700 ‫dice che le API restful dovrebbero essere stateless ed è 23 00:01:08,700 --> 00:01:12,293 ‫per questo che stiamo optando per una soluzione come i JWT. 24 00:01:13,130 --> 00:01:15,960 ‫Quindi ora diamo un'occhiata a come funziona effettivamente 25 00:01:15,960 --> 00:01:18,660 ‫l'autenticazione con i token Web Json. 26 00:01:18,660 --> 00:01:21,600 ‫E supponendo che abbiamo già un utente registrato nel 27 00:01:21,600 --> 00:01:25,380 ‫nostro database, questo è il modo in cui un utente accede all'app. 28 00:01:25,380 --> 00:01:28,700 ‫Quindi il client dell'utente inizia effettuando una richiesta di 29 00:01:28,700 --> 00:01:32,330 ‫posta con il nome utente o l'e-mail e la password. 30 00:01:32,330 --> 00:01:35,400 ‫L'applicazione verifica quindi se l'utente esiste e se 31 00:01:35,400 --> 00:01:37,430 ‫la password è corretta. 32 00:01:37,430 --> 00:01:40,340 ‫E in tal caso, viene creato un 33 00:01:40,340 --> 00:01:44,010 ‫token Web Json univoco solo per quell'utente utilizzando una stringa 34 00:01:44,010 --> 00:01:46,290 ‫segreta archiviata su un server. 35 00:01:46,290 --> 00:01:49,410 ‫E un JWT stesso è in realtà solo una stringa che 36 00:01:49,410 --> 00:01:51,150 ‫assomiglia a qualcosa del genere. 37 00:01:51,150 --> 00:01:54,170 ‫Ma parleremo di più del JWT stesso 38 00:01:54,170 --> 00:01:55,770 ‫nella prossima diapositiva. 39 00:01:55,770 --> 00:02:00,440 ‫Ad ogni modo, il server invia quindi quel JWT al client che 40 00:02:00,440 --> 00:02:04,160 ‫lo memorizzerà in un cookie o nella memoria locale. 41 00:02:04,160 --> 00:02:06,930 ‫E proprio in questo modo l'utente viene 42 00:02:06,930 --> 00:02:09,570 ‫autenticato e sostanzialmente connesso alla 43 00:02:09,570 --> 00:02:12,720 ‫nostra applicazione senza lasciare alcuno stato sul server. 44 00:02:12,720 --> 00:02:16,310 ‫Quindi il server in effetti non sa quali utenti 45 00:02:16,310 --> 00:02:17,930 ‫hanno effettivamente effettuato l'accesso. 46 00:02:17,930 --> 00:02:20,960 ‫Ma, naturalmente, l'utente sa di aver effettuato 47 00:02:20,960 --> 00:02:25,040 ‫l'accesso perché dispone di un token Web Json valido che è 48 00:02:25,040 --> 00:02:29,270 ‫un po' come un passaporto per accedere a parti protette dell'applicazione. 49 00:02:29,270 --> 00:02:32,470 ‫Quindi di nuovo, solo per essere sicuro di aver reso l'idea. 50 00:02:32,470 --> 00:02:35,330 ‫Un utente effettua l'accesso non appena recupera il 51 00:02:35,330 --> 00:02:39,720 ‫suo token Web Json valido univoco che non viene salvato da nessuna 52 00:02:39,720 --> 00:02:41,030 ‫parte sul server. 53 00:02:41,030 --> 00:02:44,840 ‫E quindi questo processo è quindi completamente apolide. 54 00:02:44,840 --> 00:02:49,300 ‫Quindi, ogni volta che un utente desidera accedere a una route protetta, ad 55 00:02:49,300 --> 00:02:51,940 ‫esempio i dati del suo profilo utente, 56 00:02:51,940 --> 00:02:55,360 ‫invia il suo token Web Json insieme a una richiesta. 57 00:02:55,360 --> 00:02:58,480 ‫Quindi è un po' come mostrare il passaporto per avere 58 00:02:58,480 --> 00:03:00,450 ‫accesso a quel percorso, giusto? 59 00:03:00,450 --> 00:03:03,870 ‫E questo è probabilmente il modo migliore e più semplice 60 00:03:03,870 --> 00:03:05,320 ‫per comprendere l'intera idea. 61 00:03:05,320 --> 00:03:07,910 ‫Ora, una volta che la richiesta raggiunge il 62 00:03:07,910 --> 00:03:11,140 ‫server, la nostra app verificherà se il token Web Json 63 00:03:11,140 --> 00:03:12,580 ‫è effettivamente valido. 64 00:03:12,580 --> 00:03:15,760 ‫Quindi, se l'utente è davvero chi dice di essere. 65 00:03:15,760 --> 00:03:17,710 ‫E di più su come funziona questo passaggio 66 00:03:17,710 --> 00:03:19,660 ‫un po' più avanti in questo video. 67 00:03:19,660 --> 00:03:22,710 ‫Ora, se il token è effettivamente valido, 68 00:03:22,710 --> 00:03:26,210 ‫i dati richiesti verranno inviati al client e, in caso 69 00:03:26,210 --> 00:03:29,400 ‫contrario, si verificherà un errore che informa l'utente 70 00:03:29,400 --> 00:03:32,600 ‫che non è autorizzato ad accedere a quella risorsa. 71 00:03:32,600 --> 00:03:34,880 ‫E finché l'utente è connesso, è 72 00:03:34,880 --> 00:03:38,230 ‫così che funzionerà ogni volta che richiede dati da 73 00:03:38,230 --> 00:03:39,843 ‫qualsiasi percorso protetto. 74 00:03:40,840 --> 00:03:43,000 ‫Ora, ciò che è molto 75 00:03:43,000 --> 00:03:47,570 ‫importante notare qui è che tutta questa comunicazione deve avvenire tramite https. 76 00:03:47,570 --> 00:03:51,510 ‫Così sicuro http crittografato in modo da impedire 77 00:03:51,510 --> 00:03:55,840 ‫che chiunque possa accedere a password o token Web Json. 78 00:03:55,840 --> 00:03:59,090 ‫Solo così abbiamo un sistema davvero sicuro. 79 00:03:59,090 --> 00:04:02,430 ‫Ma ne parleremo più avanti nella sezione, ok. 80 00:04:02,430 --> 00:04:05,120 ‫Quindi so che questo può sembrare piuttosto confuso 81 00:04:05,120 --> 00:04:06,900 ‫all'inizio quando provi per 82 00:04:06,900 --> 00:04:09,120 ‫la prima volta a girarci intorno, 83 00:04:09,120 --> 00:04:13,490 ‫ma in realtà il principio stesso è in realtà abbastanza semplice, va bene? 84 00:04:13,490 --> 00:04:15,830 ‫E questo è davvero tutto 85 00:04:15,830 --> 00:04:20,370 ‫ciò che devi sapere per poter implementare l'autenticazione utilizzando JWT. 86 00:04:20,370 --> 00:04:22,740 ‫Ma ora analizziamo un po' 87 00:04:22,740 --> 00:04:25,880 ‫più a fondo il funzionamento del JWT stesso. 88 00:04:25,880 --> 00:04:30,310 ‫Quindi un token Web Json sembra la parte sinistra di questo screenshot che è 89 00:04:30,310 --> 00:04:35,310 ‫stato preso dal debugger JWT su jwt. io. 90 00:04:35,940 --> 00:04:38,650 ‫Quindi, essenzialmente, è una stringa di codifica 91 00:04:38,650 --> 00:04:40,430 ‫composta da tre parti. 92 00:04:40,430 --> 00:04:44,140 ‫L'intestazione, il payload e la firma. 93 00:04:44,140 --> 00:04:47,910 ‫Ora l'intestazione è solo alcuni metadati sul token stesso e 94 00:04:47,910 --> 00:04:50,910 ‫il carico utile sono i dati che 95 00:04:50,910 --> 00:04:54,470 ‫possiamo codificare nel token, tutti i dati che vogliamo davvero. 96 00:04:54,470 --> 00:04:56,690 ‫Quindi più dati vogliamo codificare qui, 97 00:04:56,690 --> 00:04:58,890 ‫più grande è il JWT. 98 00:04:58,890 --> 00:05:01,750 ‫Ad ogni modo, queste due parti sono 99 00:05:01,750 --> 00:05:04,860 ‫solo testo normale che verrà codificato, ma non crittografato. 100 00:05:04,860 --> 00:05:08,790 ‫Quindi chiunque sarà in grado di decodificarli e leggerli. 101 00:05:08,790 --> 00:05:11,730 ‫Quindi non possiamo memorizzare alcun dato sensibile qui. 102 00:05:11,730 --> 00:05:13,460 ‫Ma questo non è 103 00:05:13,460 --> 00:05:16,580 ‫affatto un problema perché nella terza parte, quindi nella 104 00:05:16,580 --> 00:05:19,370 ‫firma, è dove le cose si fanno davvero interessanti. 105 00:05:19,370 --> 00:05:22,990 ‫La firma viene creata utilizzando l'intestazione, il payload e 106 00:05:22,990 --> 00:05:26,020 ‫il segreto che viene salvato sul server. 107 00:05:26,020 --> 00:05:27,080 ‫Ricordati che? 108 00:05:27,080 --> 00:05:28,760 ‫E l'intero processo viene 109 00:05:28,760 --> 00:05:30,883 ‫quindi chiamato firma del token Web Json. 110 00:05:31,900 --> 00:05:35,590 ‫Quindi, di nuovo, l'algoritmo di firma prende 111 00:05:35,590 --> 00:05:40,590 ‫l'intestazione, il payload e il segreto per creare una firma univoca. 112 00:05:40,650 --> 00:05:43,200 ‫Quindi solo questi dati più 113 00:05:43,200 --> 00:05:46,160 ‫il segreto possono creare questa firma, ok? 114 00:05:46,160 --> 00:05:49,200 ‫Quindi, insieme all'intestazione e al payload, 115 00:05:49,200 --> 00:05:52,310 ‫queste firme formano il JWT, che 116 00:05:52,310 --> 00:05:55,190 ‫viene quindi inviato al client. 117 00:05:55,190 --> 00:05:58,320 ‫Ora, come ho accennato brevemente, proprio nella prima 118 00:05:58,320 --> 00:06:02,000 ‫diapositiva, una volta che il server riceve un JWT per 119 00:06:02,000 --> 00:06:05,010 ‫concedere l'accesso a un percorso protetto, deve verificarlo 120 00:06:05,010 --> 00:06:07,730 ‫per determinare se l'utente è davvero 121 00:06:07,730 --> 00:06:10,120 ‫chi afferma di essere, giusto? 122 00:06:10,120 --> 00:06:13,890 ‫In altre parole, verificherà se nessuno ha modificato l'intestazione e 123 00:06:13,890 --> 00:06:16,580 ‫i dati del payload del token. 124 00:06:16,580 --> 00:06:20,030 ‫Quindi, ancora una volta, questo passaggio di verifica verificherà 125 00:06:20,030 --> 00:06:23,350 ‫se nessuna terza parte ha effettivamente alterato l'intestazione 126 00:06:23,350 --> 00:06:26,280 ‫o il payload del token Web Json. 127 00:06:26,280 --> 00:06:29,650 ‫Quindi, come funziona effettivamente questa verifica? 128 00:06:29,650 --> 00:06:32,560 ‫Beh, in realtà è abbastanza semplice. 129 00:06:32,560 --> 00:06:35,410 ‫Quindi, una volta ricevuto il JWT, la 130 00:06:35,410 --> 00:06:38,920 ‫verifica prenderà l'intestazione e il payload e insieme 131 00:06:38,920 --> 00:06:41,540 ‫al segreto che è ancora 132 00:06:41,540 --> 00:06:45,440 ‫salvato sul server, creerà fondamentalmente una firma di prova. 133 00:06:45,440 --> 00:06:48,390 ‫Ma la firma originale che è stata generata 134 00:06:48,390 --> 00:06:53,390 ‫quando il JWT è stato creato per la prima volta è ancora nel token, giusto? 135 00:06:53,930 --> 00:06:56,550 ‫E questa è la chiave per questa verifica. 136 00:06:56,550 --> 00:06:59,180 ‫Perché ora tutto ciò che dobbiamo fare 137 00:06:59,180 --> 00:07:02,590 ‫è confrontare la firma di prova con la firma originale. 138 00:07:02,590 --> 00:07:05,050 ‫E se la firma del 139 00:07:05,050 --> 00:07:08,460 ‫test è la stessa della firma originale, significa che 140 00:07:08,460 --> 00:07:11,760 ‫il payload e l'intestazione non sono stati modificati, giusto? 141 00:07:11,760 --> 00:07:13,690 ‫Perché se fossero stati 142 00:07:13,690 --> 00:07:16,720 ‫modificati, la firma del test dovrebbe essere diversa. 143 00:07:16,720 --> 00:07:19,600 ‫Pertanto in questo caso in cui non 144 00:07:19,600 --> 00:07:22,990 ‫vi è stata alterazione dei dati, possiamo quindi autenticare l'utente. 145 00:07:22,990 --> 00:07:24,940 ‫E ovviamente, se le 146 00:07:24,940 --> 00:07:27,520 ‫due firme sono effettivamente diverse, beh, allora 147 00:07:27,520 --> 00:07:29,870 ‫significa che qualcuno ha manomesso i dati. 148 00:07:29,870 --> 00:07:32,780 ‫Di solito provando a cambiare il payload. 149 00:07:32,780 --> 00:07:35,470 ‫Ma quella terza parte che manipola il 150 00:07:35,470 --> 00:07:38,750 ‫carico utile ovviamente non ha accesso al segreto, quindi 151 00:07:38,750 --> 00:07:41,370 ‫non può firmare il JWT. 152 00:07:41,370 --> 00:07:44,320 ‫Quindi la firma originale non corrisponderà mai 153 00:07:44,320 --> 00:07:46,050 ‫ai dati manipolati. 154 00:07:46,050 --> 00:07:49,160 ‫E quindi, la verifica fallirà sempre in 155 00:07:49,160 --> 00:07:50,700 ‫questo caso. 156 00:07:50,700 --> 00:07:53,850 ‫E questa è la chiave per far funzionare l'intero sistema. 157 00:07:53,850 --> 00:07:57,190 ‫È la magia che rende JWT così 158 00:07:57,190 --> 00:07:59,790 ‫semplice, ma anche estremamente potente. 159 00:07:59,790 --> 00:08:01,560 ‫Quindi permettetemi di riassumerlo di nuovo. 160 00:08:01,560 --> 00:08:04,830 ‫Senza il segreto, nessuno sarà in grado di manipolare 161 00:08:04,830 --> 00:08:07,920 ‫i dati JWT perché non possono creare una 162 00:08:07,920 --> 00:08:10,960 ‫firma valida per i nuovi dati. 163 00:08:10,960 --> 00:08:13,570 ‫Voglio dire, potrebbero ovviamente manipolare i 164 00:08:13,570 --> 00:08:16,870 ‫dati, ma fallirà sempre il passaggio di verifica. 165 00:08:16,870 --> 00:08:19,900 ‫Ora, non preoccuparti, non implementeremo questi 166 00:08:19,900 --> 00:08:22,660 ‫algoritmi JWT da soli. 167 00:08:22,660 --> 00:08:24,830 ‫Sono molto complessi e non 168 00:08:24,830 --> 00:08:27,060 ‫reinventeremo la ruota qui, va bene? 169 00:08:27,060 --> 00:08:29,910 ‫Ma è ancora molto importante capire effettivamente come 170 00:08:29,910 --> 00:08:32,110 ‫funziona l'intero processo dietro le quinte. 171 00:08:32,110 --> 00:08:35,570 ‫E spero che questa conferenza abbia fatto proprio questo per te. 172 00:08:35,570 --> 00:08:38,370 ‫Ma ora, passiamo alla prossima lezione per iniziare 173 00:08:38,370 --> 00:08:40,433 ‫a usare effettivamente tutto questo.