OAuth et connexion tierce : le principe, les pièges
10 min · Intermédiaire · 7 août 2026
Autorisation, pas authentification
Le bouton « Se connecter avec Google » repose sur OAuth, un protocole conçu à l’origine pour l’autorisation : permettre à une application d’accéder à certaines données d’un compte (« autorise cette application à lire ton adresse e-mail »), sans jamais lui révéler le mot de passe du compte. L’utiliser pour se connecter (prouver une identité) est un usage construit par-dessus, formalisé par une extension nommée OpenID Connect.
Info
Cette distinction n’est pas qu’un détail de vocabulaire : un jeton d’accès OAuth mal vérifié comme preuve d’identité, sans passer par les garanties d’OpenID Connect, peut laisser une application se faire passer pour authentifiée alors qu’elle ne l’est pas réellement.
Le parcours de redirection
1. L'application redirige l'utilisateur vers le fournisseur (Google, GitHub...)
avec un parametre "state" genere pour cette tentative precise
2. L'utilisateur s'authentifie chez le fournisseur et autorise l'acces demande
3. Le fournisseur redirige l'utilisateur vers l'application, avec un code
d'autorisation et le meme parametre "state"
4. L'application verifie que "state" correspond bien a la tentative qu'elle
a initiee, puis echange le code contre un jeton d'acces (cote serveur)Le piège sans le paramètre state
Sans vérification de state, un attaquant peut démarrer lui-même un flux OAuth vers l’étape 1, récupérer le code d’autorisation qui lui est destiné à l’étape 3, puis piéger sa victime pour qu’elle poursuive ce flux à sa place (par exemple en lui envoyant le lien de redirection). L’application, ne vérifiant aucune correspondance, associe alors le compte tiers de l’attaquant à la session de la victime : un détournement de compte sans jamais avoir touché à son mot de passe.