Vérifier un jeton d'identité Google côté serveur

Je ne fais pas la danse de redirection OAuth côté serveur — ça se passe côté client avec le SDK de Google. Le rôle du back-end est de vérifier le jeton d'identité que le front-end remonte après la connexion.

const client = new OAuth2Client(GOOGLE_CLIENT_ID);
const ticket = await client.verifyIdToken({
  idToken,
  audience: GOOGLE_CLIENT_ID,
});
const payload = ticket.getPayload(); // { email, email_verified, name, sub, ... }

Le back-end fait confiance à payload.sub et payload.email pour trouver ou créer l'utilisateur local, puis émet son propre JWT de session.

Ne fais jamais confiance à ce que le front-end prétend sur l'identité sans vérification indépendante. Un client pourrait être modifié pour envoyer une fausse charge pour n'importe quelle adresse. verifyIdToken vérifie cryptographiquement que le jeton a bien été signé par Google pour cette audience précise et n'a pas expiré. Saute ça et fais confiance à une affirmation « je me suis connecté en tant que [email protected] » envoyée par le client — c'est un contournement d'authentification complet.

Le paramètre audience compte plus qu'il n'y paraît. Il doit correspondre exactement à l'identifiant client enregistré de l'application. Sans lui, un jeton valide émis pour une autre application pourrait être rejoué contre ce back-end — Google signe le jeton, mais la revendication d'audience est ce qui le limite à une application précise. Facile à sauter, vraie vulnérabilité si sauté.

Décide d'entrée comment la connexion Google interagit avec un compte à mot de passe existant sous le même e-mail — lie automatiquement par e-mail vérifié seulement quand email_verified: true (Google peut émettre des jetons pour des e-mails non vérifiés dans certains flux), ou force une étape de liaison explicite. La liaison automatique sur un e-mail non vérifié est un vrai vecteur de prise de contrôle de compte.

Une note opérationnelle : les identifiants client et les URI de redirection sont propres à l'environnement. Un « marche en local, casse dans Docker ou en prod » récurrent, c'est que le bon GOOGLE_CLIENT_ID n'atteint pas réellement le conteneur, plutôt qu'un défaut codé en dur commité. Et Google rejette purement et simplement les URI de redirection en IP de LAN — tout ce qui est piloté depuis un appareil physique sur le réseau local échoue chez le fournisseur, pas dans ton code, et ça ressemble à un bug d'intégration à chaque fois.