Scegliere un metodo\/fornitore di autenticazione<\/h2>\n
Esistono praticamente 1.000 modi per integrare l’autenticazione in un’applicazione. Piuttosto che concentrarci su particolari provider (argomento per un altro post del blog), esaminiamo i tipi di soluzioni di autenticazione<\/strong> e alcuni esempi di ciascuna. In termini di implementazione, next-auth<\/a> sta rapidamente diventando un’opzione popolare per integrare l’applicazione Next.js con pi\u00f9 provider, aggiungere SSO, ecc.<\/p>\n Questa soluzione \u00e8 semplicissima: si memorizzano nomi utente e password in un database relazionale. Quando un utente si iscrive per la prima volta, si inserisce una nuova riga nella tabella `users` con le informazioni fornite. Quando l’utente accede, si verifica che le sue credenziali corrispondano a quelle memorizzate nella tabella. Quando un utente vuole cambiare la propria password, si aggiorna il valore nella tabella.<\/p>\n L’autenticazione tradizionale su database \u00e8 sicuramente lo schema di autenticazione pi\u00f9 diffuso, se si considera la totalit\u00e0 delle applicazioni esistenti, ed esiste praticamente da sempre. \u00c8 molto flessibile, economico e non vincola a nessun fornitore in particolare. Ma \u00e8 necessario costruirlo da soli e, in particolare, preoccuparsi della crittografia e assicurarsi che quelle preziosissime password non finiscano nelle mani sbagliate.<\/p>\n Negli ultimi anni (e, per quanto riguarda Firebase, gi\u00e0 da qualche anno), i fornitori di database gestiti sono diventati relativamente standard nell’offrire una sorta di soluzione di autenticazione gestita. Firebase<\/a>, Supabase<\/a> e AWS<\/a> offrono sia un database gestito che un’autenticazione gestita come servizio attraverso una suite di API che astrae facilmente dalla creazione di utenti e dalla gestione delle sessioni (per saperne di pi\u00f9, proseguite nella lettura).<\/p>\n L’accesso di un utente con l’autenticazione Supabase \u00e8 semplice<\/a>:<\/p>\n Forse ancora pi\u00f9 comune dell’autenticazione come servizio del DBaaS \u00e8 l’autenticazione come servizio di un’intera azienda o prodotto. Auth0<\/a> esiste dal 2013 (ora \u00e8 di propriet\u00e0 di Okta) e le recenti aggiunte come Stytch<\/a> hanno dato priorit\u00e0 all’esperienza degli sviluppatori e hanno guadagnato un po’ di spazio.<\/p>\n L’SSO permette di “esternalizzare” l’identit\u00e0 a un fornitore esterno, che pu\u00f2 spaziare da un fornitore aziendale focalizzato sulla sicurezza come Okta<\/a> a qualcosa di pi\u00f9 diffuso come Google<\/a> o GitHub. Google SSO \u00e8 onnipresente nel mondo SaaS, mentre alcuni strumenti dedicati agli sviluppatori effettuano l’autenticazione solo<\/em> tramite GitHub.<\/p>\n Qualunque fornitore si scelga, SSO \u00e8 generalmente un’aggiunta agli altri tipi di autenticazione di cui sopra e comporta le sue peculiarit\u00e0<\/a> per quanto riguarda l’integrazione con piattaforme esterne (attenzione: SAML utilizza XML).<\/p>\n Non esiste una scelta “corretta”: ci\u00f2 che \u00e8 giusto per il proprio progetto dipende dalle proprie priorit\u00e0. Se volete fare le cose in fretta senza un sacco di configurazioni iniziali, l’outsourcing dell’autenticazione ha senso (anche esternalizzarla completamente, UI inclusa, a qualcuno come Auth0). Se invece prevedete una configurazione pi\u00f9 complessa, \u00e8 opportuno costruire il proprio backend di autenticazione. E se pensate di supportare clienti pi\u00f9 grandi, prima o poi dovrete aggiungere il SSO.<\/p>\n Next.js \u00e8 cos\u00ec popolare che la maggior parte di questi fornitori di autenticazione hanno documenti e guide all’integrazione specifiche per Next.js.<\/p>\n Alcuni fornitori di autenticazione, come Auth0, forniscono intere pagine web ospitate per la registrazione e l’accesso. Ma se state costruendo queste pagine da zero, trovo che sia utile crearle all’inizio del processo, perch\u00e9 vi serviranno come reindirizzamento quando implementerete l’autenticazione.<\/p>\n Quindi ha senso creare la struttura di queste pagine e poi aggiungere le richieste al backend in un secondo momento. Il modo pi\u00f9 semplice per implementare l’autenticazione \u00e8 avere due di queste route:<\/p>\n Oltre alle basi, dovrete occuparvi di casi limite, come quando un utente dimentica la password. Alcuni team preferiscono inserire il processo di reimpostazione della password in un percorso separato, mentre altri aggiungono elementi dinamici dell’interfaccia utente alla normale pagina di accesso.<\/p>\n Una bella pagina di iscrizione potrebbe non fare la differenza tra successo e fallimento, ma piccoli accorgimenti possono lasciare una buona impressione e fornire una migliore UX. Eccone alcuni raccolti da siti di tutto il web che hanno messo un po’ di cura in pi\u00f9 nei loro processi di autenticazione.<\/p>\n La call to action nella navbar di Stripe cambia in base alla presenza o meno di una sessione autenticata. Ecco come appare il sito di marketing se non si \u00e8 autenticati. Notate la call to action per accedere:<\/p>\n Ecco come appare se siete autenticati. Notate che la call to action cambia per portare l’utente alla sua dashboard invece che all’accesso:<\/p>\n Non cambia poi molto la mia esperienza con Stripe, ma \u00e8 utile.<\/p>\n Un interessante inciso tecnico: c’\u00e8 una buona ragione per cui la maggior parte delle aziende non fa “dipendere” la navbar del proprio sito di marketing dall’autenticazione: significherebbe una richiesta API aggiuntiva per verificare lo stato di autenticazione su ogni singolo caricamento di pagina, la maggior parte dei quali riguarda visitatori che probabilmente non sono autenticati.<\/p>\n Negli ultimi anni, soprattutto nel settore SaaS, le aziende hanno iniziato ad aggiungere contenuti alla pagina di iscrizione per “incoraggiare” l’utente a completare l’iscrizione. Questo pu\u00f2 aiutare a migliorare la conversione della pagina, almeno in modo incrementale.<\/p>\n Ecco una pagina di iscrizione di Retool, con un’animazione e alcuni loghi laterali:<\/p>\n Anche noi di Kinsta facciamo cos\u00ec per la nostra pagina di iscrizione:<\/p>\n Un piccolo contenuto extra pu\u00f2 aiutare a ricordare all’utente per cosa si sta iscrivendo e perch\u00e9 ne ha bisogno.<\/p>\n Mi sento di affermare che gli sviluppatori sanno bene che le password sono intrinsecamente insicure, ma non<\/em> \u00e8 cos\u00ec per tutte le persone che si iscriveranno al prodotto. Incoraggiare gli utenti a creare password sicure \u00e8 un bene per voi e per loro.<\/p>\n Coinbase \u00e8 molto severo per quanto riguarda l’iscrizione e richiede l’utilizzo di una password sicura e pi\u00f9 complicata del semplice nome di battesimo:<\/p>\n Dopo averne generata una dal mio gestore di password, ero pronto a partire:<\/p>\n L’interfaccia utente, per\u00f2, non mi diceva perch\u00e9<\/em> la password non era abbastanza sicura, n\u00e9 i requisiti oltre alla presenza di un numero. Includere questi requisiti nel copy del prodotto render\u00e0 le cose pi\u00f9 semplici per l’utente e aiuter\u00e0 a evitare la frustrazione da ripetizione della password.<\/p>\n Un americano su tre usa un gestore di password come 1Password<\/a>, eppure molti moduli sul web continuano a ignorare il `type=` negli input HTML. Fate in modo che i moduli giochino con i gestori di password<\/a>:<\/p>\n Pu\u00f2 fare la differenza tra un’iscrizione di 10 secondi, incredibilmente fluida, e una fastidiosa iscrizione manuale, soprattutto su mobile.<\/p>\n Una volta avvenuta l’autenticazione dell’utente, \u00e8 il momento di scegliere una strategia per mantenere lo stato durante le richieste successive. L’HTTP \u00e8 stateless e non vogliamo certo chiedere all’utente la sua password a ogni singola richiesta. Esistono due metodi popolari per gestire questo aspetto<\/a>: le sessioni<\/strong> (o cookie) e i JWT<\/strong> (JSON web token), che si differenziano per il fatto che il lavoro venga svolto dal server o dal client.<\/p>\n Nell’autenticazione basata sulle sessioni, la logica e il lavoro per mantenere l’autenticazione sono gestiti dal server<\/strong>. Ecco il flusso di base:<\/p>\n Per quanto riguarda la durata delle sessioni, il momento in cui devono essere revocate, ecc., \u00e8 tutto piuttosto semplice e modificabile. L’aspetto negativo \u00e8 la latenza su scala significativa, viste tutte le scritture e le letture del database, ma questo potrebbe non essere un aspetto importante per la maggior parte dei lettori.<\/p>\n Invece di gestire l’autenticazione per le richieste successive sul server, i JWT<\/a> permettono di gestirle (per lo pi\u00f9) sul lato client<\/strong>. Ecco come funziona:<\/p>\n Con tutto il lavoro successivo all’autenticazione iniziale scaricato sul client, l’applicazione pu\u00f2 essere caricata e funzionare molto pi\u00f9 velocemente. Ma c’\u00e8 un problema principale: non c’\u00e8 modo di invalidare un JWT dal server. Se l’utente vuole disconnettersi da un dispositivo o se l’ambito della sua autorizzazione cambia, dovrete aspettare che il JWT scada.<\/p>\n Parte di ci\u00f2 che rende grande Next.js \u00e8 il rendering statico integrato: se la pagina \u00e8 statica, cio\u00e8 non deve effettuare chiamate API esterne, Next.js la memorizza automaticamente nella cache e pu\u00f2 servirla in modo estremamente veloce tramite un CDN. Le versioni precedenti a Next.js 13 sanno se una pagina \u00e8 statica se non include alcun `getServerSideProps` o `getInitialProps` nel file, mentre le versioni successive a Next.js 13 utilizzano React Server Components<\/a> per farlo.<\/p>\n Per quanto riguarda l’autenticazione, avete la possibilit\u00e0 di scegliere<\/a> tra il rendering di una pagina statica di “caricamento” e l’esecuzione del fetching sul lato client o l’esecuzione di tutto sul lato server. Per le pagine che richiedono l’autenticazione[1]<\/a>, potete eseguire il rendering di uno “scheletro” statico e poi effettuare le richieste di autenticazione sul lato client. In teoria, questo significa che la pagina si carica pi\u00f9 velocemente, anche se il contenuto iniziale non \u00e8 completamente pronto.<\/p>\n Ecco un esempio semplificato tratto dai documenti che rende uno stato di caricamento finch\u00e9 l’oggetto utente non \u00e8 pronto:<\/p>\n Si noti che \u00e8 necessario creare una sorta di UI di caricamento per occupare lo spazio mentre il client effettua le richieste dopo il caricamento.<\/p>\n Se volete semplificare le cose ed eseguire l’autenticazione lato server, potete aggiungere la richiesta di autenticazione alla funzione `getServerSideProps` e Next aspetter\u00e0 il rendering della pagina fino al completamento della richiesta. Al posto della logica condizionale dello snippet qui sopra, potreste eseguire qualcosa di pi\u00f9 semplice come questa versione semplificata dei documenti di Next:<\/p>\n Qui c’\u00e8 ancora la logica per gestire il fallimento dell’autenticazione, ma si reindirizza al login invece di eseguire il rendering dello stato di caricamento.<\/p>\n Qual \u00e8 la soluzione giusta per il vostro progetto? Iniziate valutando quanto siete sicuri della velocit\u00e0 dello schema di autenticazione. Se le richieste non richiedono tempo, potete eseguirle lato server ed evitare lo stato di caricamento. Se volete dare priorit\u00e0 al rendering immediato e poi attendere la richiesta, saltate `getServerSideProps` ed eseguite l’autenticazione altrove.<\/p>\nDatabase tradizionale<\/h3>\n
Soluzioni di autenticazione dal fornitore di database<\/h3>\n
async function signInWithEmail() {\n const { data, error } = await supabase.auth.signInWithPassword({\n email: 'example@email.com',\n password: 'example-password',\n })\n}<\/code><\/pre>\nSoluzioni di autenticazione che non provengono dal proprio fornitore di database<\/h3>\n
![\"L'interfaccia](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/Auth0-authentication.png\")
Single Sign On<\/h3>\n
Ok, allora quale scegliere?<\/h3>\n
Creazione di route per l’iscrizione e l’accesso e suggerimenti per raggiungere un livello di autenticazione extra<\/strong><\/h2>\n
\n
1. Barra di navigazione aggiornata quando c’\u00e8 una sessione attiva<\/h3>\n
![\"Homepage](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/stripe-homepage.png\")
![\"Differenze](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/stripe-homepage-changes.png\")
2. Contenuti utili aggiunti al modulo di iscrizione<\/h3>\n
![\"Pagina](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/retool-signup-page.png\")
![\"Pagina](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/mykinsta-sign-in.png\")
3. Se si usa una password: suggerirne o imporne una forte<\/h3>\n
![\"Creare](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/coinbase-create-account.png\")
![\"Password](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/coinbase-password-strength.png\")
4. Etichettare gli input in modo da renderli compatibili con un gestore di password<\/h3>\n
\n
Scegliere tra sessioni e JWT<\/strong><\/h2>\n
Sessioni, ovvero cookie<\/h3>\n
\n
Gettoni web JSON (JWT)<\/h3>\n
\n
Scegliere tra autorizzazione lato server e lato client<\/strong><\/h2>\n
import useUser from '..\/lib\/useUser'\n \nconst Profile = () => {\n \/\/ Fetch the user client-side\n const { user } = useUser({ redirectTo: '\/login' })\n \n \/\/ Server-render loading state\n if (!user || user.isLoggedIn === false) {\n \/\/ Build some sort of loading page here\n return <div>Loading...<\/div>\n }\n \n \/\/ Once the user request finishes, show the user\n return (\n <div>\n <h1>Your Account<\/h1>\n <p>Username: {JSON.stringify(user.username,null)}<\/p>\n <p>Email: {JSON.stringify(user.email,null)}<\/p>\n <p>Address: {JSON.stringify(user.address,null)}<\/p>\n <\/div>\n )\n}\n \nexport default Profile<\/code><\/pre>\nimport withSession from '..\/lib\/session'\n \nexport const getServerSideProps = withSession(async function ({ req, res }) {\n const { user } = req.session\n \n if (!user) {\n return {\n redirect: {\n destination: '\/login',\n permanent: false,\n },\n }\n }\n \n return {\n props: { user },\n }\n})\n \nconst Profile = ({ user }) => {\n \/\/ Show the user. No loading state is required\n return (\n <div>\n <h1>Your Account<\/h1>\n <p>Username: {JSON.stringify(user.username,null)}<\/p>\n <p>Email: {JSON.stringify(user.email,null)}<\/p>\n <p>Address: {JSON.stringify(user.address,null)}<\/p>\n <\/div>\n )\n}\n \nexport default Profile<\/code><\/pre>\nRiepilogo<\/h2>\n