In breve
OAuth è lo standard che lascia un utente accedere alla tua applicazione con un account esistente, come Google o GitHub, senza mai darti la sua password. Quando clicchi su "Continua con Google", OAuth è ciò che succede in background: Google conferma chi è l'utente e lo dice alla tua applicazione, così tu non vedi né memorizzi mai la sua password. È più comodo per gli utenti e più sicuro per te, perché detieni meno secret.
Come si svolge il flusso
Mandi l'utente dal fornitore (diciamo Google) per accedere. Lui accetta di condividere qualche informazione di base con la tua applicazione. Il fornitore rimanda poi l'utente alla tua applicazione, con una prova di chi è. La tua applicazione si fida di questa prova, invece di gestire una password essa stessa.
Perché è più sicuro
Memorizzare correttamente delle password è davvero difficile e pericoloso se lo si fa male. OAuth significa che non memorizzi nessuna password, quindi un'intera categoria di rischio di sicurezza sparisce. Il fornitore si fa carico delle parti difficili, comprese cose come l'autenticazione a due fattori, al posto tuo.
Di solito non lo costruisci tu stesso
OAuth ha molti piccoli dettagli sensibili per la sicurezza, quindi quasi nessuno lo implementa a mano. Al suo posto, usi un servizio di autenticazione come Clerk, che lo racchiude in qualche componente. Attivi "Login con Google", e il servizio si fa carico del flusso, così puoi concentrarti sul tuo vero prodotto.
Confusioni frequenti dei principianti
Le persone mescolano spesso tre termini vicini. L'autenticazione consiste nel dimostrare chi sei (accedere), l'autorizzazione è ciò che hai il diritto di fare una volta dentro, e OAuth è lo standard che lascia un fornitore farsi carico della parte di prova per te. Una seconda confusione è pensare che OAuth significhi non poter più offrire il login con email e password; puoi farlo, e la maggior parte delle applicazioni offre entrambi affiancati. Una terza è lo scarto tra sviluppo e produzione: il login social di solito funziona con credenziali di test durante la costruzione, e poi richiede un passaggio accurato alle vere impostazioni del fornitore prima del lancio. Poiché un servizio di auth gestisce tutto questo, il tuo compito è soprattutto configurazione, non crittografia, il che è esattamente perché è la via consigliata.