En bref
OAuth est le standard qui laisse un utilisateur se connecter à votre application avec un compte existant, comme Google ou GitHub, sans jamais vous donner son mot de passe. Quand vous cliquez sur "Continuer avec Google", OAuth est ce qui se passe en arrière-plan : Google confirme qui est l'utilisateur et le dit à votre application, pour que vous ne voyiez ni ne stockiez jamais son mot de passe. C'est plus pratique pour les utilisateurs et plus sûr pour vous, car vous détenez moins de secrets.
Comment se déroule le flux
Vous envoyez l'utilisateur chez le fournisseur (disons Google) pour se connecter. Il accepte de partager quelques informations de base avec votre application. Le fournisseur renvoie ensuite l'utilisateur vers votre application, avec une preuve de qui il est. Votre application fait confiance à cette preuve, au lieu de gérer un mot de passe elle-même.
Pourquoi c'est plus sûr
Stocker correctement des mots de passe est vraiment difficile et dangereux si on s'y prend mal. OAuth signifie que vous ne stockez aucun mot de passe, donc toute une catégorie de risque de sécurité disparaît. Le fournisseur prend en charge les parties difficiles, y compris des choses comme l'authentification à deux facteurs, à votre place.
Vous ne le construisez généralement pas vous-même
OAuth a de nombreux petits détails sensibles pour la sécurité, donc presque personne ne l'implémente à la main. À la place, vous utilisez un service d'authentification comme Clerk, qui l'emballe dans quelques composants. Vous activez "Connexion avec Google", et le service prend en charge le flux, pour que vous puissiez vous concentrer sur votre vrai produit.
Confusions fréquentes des débutants
Les gens mélangent souvent trois termes voisins. L'authentification consiste à prouver qui vous êtes (se connecter), l'autorisation est ce que vous avez le droit de faire une fois entré, et OAuth est le standard qui laisse un fournisseur prendre en charge la partie preuve pour vous. Une deuxième confusion est de penser qu'OAuth signifie que vous ne pouvez plus proposer de connexion par e-mail et mot de passe ; vous le pouvez, et la plupart des applications proposent les deux côte à côte. Une troisième est l'écart entre développement et production : la connexion sociale fonctionne généralement avec des identifiants de test pendant la construction, puis demande un passage soigneux aux vrais réglages du fournisseur avant le lancement. Comme un service d'auth gère tout cela, votre tâche est surtout de la configuration, pas de la cryptographie, ce qui est exactement pourquoi c'est la voie recommandée.