‫Istruttore: Quindi abbiamo impostato il nostro
‫modello utente pronto per salvare gli utenti con password sicure.
‫Quindi, in seguito, implementeremo
‫davvero l'autenticazione e l'autorizzazione dell'utente.
‫Quindi, in termini semplici, l'intero flusso di
‫lavoro di accesso degli utenti e
‫consentendo loro di interagire con determinate risorse protette a
‫cui gli utenti non registrati non possono accedere.
‫Ora ci sono molti metodi di autenticazione
‫là fuori, ma quello che useremo è un approccio
‫molto moderno, semplice e sicuro chiamato Json Web Tokens o JWT in breve.
‫Quindi i token Web Json sono una soluzione senza
‫stato per l'autenticazione.
‫Quindi non è necessario memorizzare alcuno stato di sessione sul
‫server, il che ovviamente è perfetto per API riposanti come quella
‫che stiamo costruendo.
‫Perché ricorda, le API restful dovrebbero sempre essere stateless.
‫E l'alternativa più utilizzata all'autenticazione con JWT
‫è semplicemente memorizzare lo stato di accesso dell'utente sul
‫server utilizzando le sessioni.
‫Ma ovviamente non segue il principio che
‫dice che le API restful dovrebbero essere stateless ed è
‫per questo che stiamo optando per una soluzione come i JWT.
‫Quindi ora diamo un'occhiata a come funziona effettivamente
‫l'autenticazione con i token Web Json.
‫E supponendo che abbiamo già un utente registrato nel
‫nostro database, questo è il modo in cui un utente accede all'app.
‫Quindi il client dell'utente inizia effettuando una richiesta di
‫posta con il nome utente o l'e-mail e la password.
‫L'applicazione verifica quindi se l'utente esiste e se
‫la password è corretta.
‫E in tal caso, viene creato un
‫token Web Json univoco solo per quell'utente utilizzando una stringa
‫segreta archiviata su un server.
‫E un JWT stesso è in realtà solo una stringa che
‫assomiglia a qualcosa del genere.
‫Ma parleremo di più del JWT stesso
‫nella prossima diapositiva.
‫Ad ogni modo, il server invia quindi quel JWT al client che
‫lo memorizzerà in un cookie o nella memoria locale.
‫E proprio in questo modo l'utente viene
‫autenticato e sostanzialmente connesso alla
‫nostra applicazione senza lasciare alcuno stato sul server.
‫Quindi il server in effetti non sa quali utenti
‫hanno effettivamente effettuato l'accesso.
‫Ma, naturalmente, l'utente sa di aver effettuato
‫l'accesso perché dispone di un token Web Json valido che è
‫un po' come un passaporto per accedere a parti protette dell'applicazione.
‫Quindi di nuovo, solo per essere sicuro di aver reso l'idea.
‫Un utente effettua l'accesso non appena recupera il
‫suo token Web Json valido univoco che non viene salvato da nessuna
‫parte sul server.
‫E quindi questo processo è quindi completamente apolide.
‫Quindi, ogni volta che un utente desidera accedere a una route protetta, ad
‫esempio i dati del suo profilo utente,
‫invia il suo token Web Json insieme a una richiesta.
‫Quindi è un po' come mostrare il passaporto per avere
‫accesso a quel percorso, giusto?
‫E questo è probabilmente il modo migliore e più semplice
‫per comprendere l'intera idea.
‫Ora, una volta che la richiesta raggiunge il
‫server, la nostra app verificherà se il token Web Json
‫è effettivamente valido.
‫Quindi, se l'utente è davvero chi dice di essere.
‫E di più su come funziona questo passaggio
‫un po' più avanti in questo video.
‫Ora, se il token è effettivamente valido,
‫i dati richiesti verranno inviati al client e, in caso
‫contrario, si verificherà un errore che informa l'utente
‫che non è autorizzato ad accedere a quella risorsa.
‫E finché l'utente è connesso, è
‫così che funzionerà ogni volta che richiede dati da
‫qualsiasi percorso protetto.
‫Ora, ciò che è molto
‫importante notare qui è che tutta questa comunicazione deve avvenire tramite https.
‫Così sicuro http crittografato in modo da impedire
‫che chiunque possa accedere a password o token Web Json.
‫Solo così abbiamo un sistema davvero sicuro.
‫Ma ne parleremo più avanti nella sezione, ok.
‫Quindi so che questo può sembrare piuttosto confuso
‫all'inizio quando provi per
‫la prima volta a girarci intorno,
‫ma in realtà il principio stesso è in realtà abbastanza semplice, va bene?
‫E questo è davvero tutto
‫ciò che devi sapere per poter implementare l'autenticazione utilizzando JWT.
‫Ma ora analizziamo un po'
‫più a fondo il funzionamento del JWT stesso.
‫Quindi un token Web Json sembra la parte sinistra di questo screenshot che è
‫stato preso dal debugger JWT su jwt. io.
‫Quindi, essenzialmente, è una stringa di codifica
‫composta da tre parti.
‫L'intestazione, il payload e la firma.
‫Ora l'intestazione è solo alcuni metadati sul token stesso e
‫il carico utile sono i dati che
‫possiamo codificare nel token, tutti i dati che vogliamo davvero.
‫Quindi più dati vogliamo codificare qui,
‫più grande è il JWT.
‫Ad ogni modo, queste due parti sono
‫solo testo normale che verrà codificato, ma non crittografato.
‫Quindi chiunque sarà in grado di decodificarli e leggerli.
‫Quindi non possiamo memorizzare alcun dato sensibile qui.
‫Ma questo non è
‫affatto un problema perché nella terza parte, quindi nella
‫firma, è dove le cose si fanno davvero interessanti.
‫La firma viene creata utilizzando l'intestazione, il payload e
‫il segreto che viene salvato sul server.
‫Ricordati che?
‫E l'intero processo viene
‫quindi chiamato firma del token Web Json.
‫Quindi, di nuovo, l'algoritmo di firma prende
‫l'intestazione, il payload e il segreto per creare una firma univoca.
‫Quindi solo questi dati più
‫il segreto possono creare questa firma, ok?
‫Quindi, insieme all'intestazione e al payload,
‫queste firme formano il JWT, che
‫viene quindi inviato al client.
‫Ora, come ho accennato brevemente, proprio nella prima
‫diapositiva, una volta che il server riceve un JWT per
‫concedere l'accesso a un percorso protetto, deve verificarlo
‫per determinare se l'utente è davvero
‫chi afferma di essere, giusto?
‫In altre parole, verificherà se nessuno ha modificato l'intestazione e
‫i dati del payload del token.
‫Quindi, ancora una volta, questo passaggio di verifica verificherà
‫se nessuna terza parte ha effettivamente alterato l'intestazione
‫o il payload del token Web Json.
‫Quindi, come funziona effettivamente questa verifica?
‫Beh, in realtà è abbastanza semplice.
‫Quindi, una volta ricevuto il JWT, la
‫verifica prenderà l'intestazione e il payload e insieme
‫al segreto che è ancora
‫salvato sul server, creerà fondamentalmente una firma di prova.
‫Ma la firma originale che è stata generata
‫quando il JWT è stato creato per la prima volta è ancora nel token, giusto?
‫E questa è la chiave per questa verifica.
‫Perché ora tutto ciò che dobbiamo fare
‫è confrontare la firma di prova con la firma originale.
‫E se la firma del
‫test è la stessa della firma originale, significa che
‫il payload e l'intestazione non sono stati modificati, giusto?
‫Perché se fossero stati
‫modificati, la firma del test dovrebbe essere diversa.
‫Pertanto in questo caso in cui non
‫vi è stata alterazione dei dati, possiamo quindi autenticare l'utente.
‫E ovviamente, se le
‫due firme sono effettivamente diverse, beh, allora
‫significa che qualcuno ha manomesso i dati.
‫Di solito provando a cambiare il payload.
‫Ma quella terza parte che manipola il
‫carico utile ovviamente non ha accesso al segreto, quindi
‫non può firmare il JWT.
‫Quindi la firma originale non corrisponderà mai
‫ai dati manipolati.
‫E quindi, la verifica fallirà sempre in
‫questo caso.
‫E questa è la chiave per far funzionare l'intero sistema.
‫È la magia che rende JWT così
‫semplice, ma anche estremamente potente.
‫Quindi permettetemi di riassumerlo di nuovo.
‫Senza il segreto, nessuno sarà in grado di manipolare
‫i dati JWT perché non possono creare una
‫firma valida per i nuovi dati.
‫Voglio dire, potrebbero ovviamente manipolare i
‫dati, ma fallirà sempre il passaggio di verifica.
‫Ora, non preoccuparti, non implementeremo questi
‫algoritmi JWT da soli.
‫Sono molto complessi e non
‫reinventeremo la ruota qui, va bene?
‫Ma è ancora molto importante capire effettivamente come
‫funziona l'intero processo dietro le quinte.
‫E spero che questa conferenza abbia fatto proprio questo per te.
‫Ma ora, passiamo alla prossima lezione per iniziare
‫a usare effettivamente tutto questo.