OAuth expliqué à ceux qui doivent le livrer

La documentation d’OAuth est écrite pour ceux qui implémentent les fournisseurs. Presque tous ceux qui la lisent cherchent en fait à ajouter un bouton « Continuer avec Google », et l’écart entre ces deux publics explique pourquoi le sujet paraît plus difficile qu’il ne l’est.

Ce qui se passe réellement

Vous envoyez l’utilisateur chez Google avec un mot disant qui vous êtes et où le renvoyer. Il se connecte sur la page de Google — votre application ne voit jamais le mot de passe. Google le renvoie avec un code à courte durée de vie. Votre serveur échange ce code, par un canal arrière, contre un jeton qui prouve qui est l’utilisateur. C’est toute la forme du processus.

Là où ça se passe mal

• Effectuer l’échange du code dans le navigateur, ce qui expose le client secret.
• Omettre le paramètre state, qui sert précisément à empêcher une falsification de requête inter-sites sur le callback.
• Faire confiance à l’affirmation d’e-mail sans vérifier qu’elle est confirmée — un e-mail non vérifié est une prise de contrôle de compte qui n’attend que d’avoir lieu.
• Supposer que l’identifiant utilisateur du fournisseur est une adresse e-mail. Ce n’est pas le cas, et les gens changent d’adresse.
• Oublier le cas de la liaison de comptes : la même personne, un second fournisseur, deux comptes.

“La partie dangereuse d’OAuth n’est pas le protocole. Ce sont les cinq petites décisions que le tutoriel n’a pas mentionnées.”

Chacun de ces points est pris en charge pour vous lorsque l’intégration du fournisseur relève de la configuration plutôt que du code. La connexion Google est disponible sur toutes les offres Alt Auth, y compris la gratuite, et Apple, Facebook et Microsoft figurent sur les offres supérieures.