Tokens et OAuth

Quand un utilisateur se connecte

Les clés API identifient une application. Mais comment identifier un utilisateur ? Quand quelqu'un se connecte à Uber, le serveur doit savoir quel passager ou chauffeur c'est. Une clé API ne peut pas faire ça, car elle représente l'app, pas la personne qui l'utilise.

C'est là qu'interviennent les tokens.

Le flux de connexion

Voici ce qui se passe quand un utilisateur se connecte à une app. Suivons les étapes une par une.

Étape 1 : l'utilisateur envoie ses identifiants. L'app collecte l'email et le mot de passe, puis les envoie au serveur dans une requête POST :

Étape 2 : le serveur vérifie les identifiants. Il cherche l'email dans la table Users, vérifie le mot de passe, et si tout correspond, il génère un token : une longue chaîne aléatoire, similaire à une clé API mais liée à une session utilisateur spécifique.

Étape 3 : le serveur renvoie le token. La réponse ressemble à ça :

{
  "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "firstName": "Alice",
  "email": "alice@acme.com"
}

Étape 4 : l'app stocke le token et l'inclut dans chaque requête suivante. À partir de maintenant, chaque appel API porte le token dans le header Authorization :

Le mot Bearer signifie simplement "la personne qui porte ce token." Le serveur le lit, cherche à quel utilisateur il appartient, et répond avec les données de cet utilisateur.

Essayez en direct

Suivons le flux complet avec une vraie API. DummyJSON a un endpoint /auth/me qui renvoie le profil de l'utilisateur actuel, mais seulement si vous êtes authentifié.

Étape 1 : voyez l'échec. Cet endpoint a besoin d'un token. Sans lui, le serveur ne sait pas qui est "me". Essayez :

Vous devriez obtenir un 401 Unauthorized. Le serveur dit : "Qui êtes-vous ? Vous ne m'avez pas dit."

Étape 2 : connectez-vous et obtenez un token. Maintenant, authentifions-nous. Imaginez qu'Emily vient d'ouvrir l'app et a tapé son nom d'utilisateur et son mot de passe. En coulisses, l'app envoie cette requête :

Vous devriez obtenir un 200 OK. Regardez la réponse : il y a un champ accessToken avec une longue chaîne. C'est votre token. Cliquez sur le bouton Copier qui est apparu sous la réponse.

Étape 3 : utilisez le token. Maintenant collez le token que vous venez de copier dans le champ ci-dessous et cliquez sur "Envoyer la requête" :

Cette fois vous devriez obtenir un 200 OK avec le profil complet d'Emily (nom, email, âge, etc.). Même endpoint, même URL. La seule différence : vous avez inclus un token valide dans le header Authorization.

C'est tout le flux de connexion. Identifiants en entrée, token en sortie, token attaché à chaque requête après ça.

Les tokens expirent (et les refresh tokens)

Contrairement aux clés API, les tokens ne durent pas éternellement. Un access token typique expire après 15 minutes à quelques heures. C'est intentionnel : si quelqu'un vole votre token, il ne fonctionnera pas longtemps.

Mais on ne veut pas que les utilisateurs retapent leur mot de passe toutes les 15 minutes. C'est là qu'interviennent les refresh tokens. Quand le serveur renvoie un access token, il envoie souvent aussi un refresh token. Le refresh token a une durée de vie plus longue (jours ou semaines). Quand l'access token expire, l'app utilise silencieusement le refresh token pour obtenir un nouvel access token, sans déranger l'utilisateur.

Si les utilisateurs de votre produit se font déconnecter de façon aléatoire, un token expiré avec un flux de refresh cassé en est souvent la cause. C'est utile à mentionner à votre équipe technique.

Clés API vs tokens

Les deux sont des chaînes envoyées dans les headers. Les deux authentifient des requêtes. Alors quelle est la différence ?

Une clé API dit "cette requête vient de l'app Acme Dashboard." Un token dit "cette requête vient d'Alice, qui s'est connectée il y a 20 minutes."

Beaucoup d'API utilisent les deux. Mais pour la plupart des API avec lesquelles vous travaillerez, c'est l'un ou l'autre.

OAuth : "Se connecter avec Google"

Vous l'avez utilisé des centaines de fois. Vous allez sur une nouvelle app, et au lieu de créer un compte, vous cliquez sur "Se connecter avec Google." Pas de nouveau mot de passe à retenir. Quelques secondes plus tard, vous êtes connecté.

Google est le fournisseur le plus courant, mais le même mécanisme fonctionne avec Apple, Facebook, GitHub, Microsoft, X, et bien d'autres. Les boutons sont différents, le flux est le même.

C'est OAuth, et la façon la plus simple de le comprendre est avec une analogie.

Imaginez que vous visitez les bureaux d'une entreprise. Vous allez à l'accueil et dites "je suis ici pour voir Alice." La réceptionniste ne vous connaît pas, donc elle appelle Alice. Alice confirme que vous êtes attendu, et la réceptionniste vous donne un badge visiteur. Ce badge vous permet de circuler dans le bâtiment pour la journée, mais il expire quand vous partez.

Dans OAuth :

• Vous êtes l'utilisateur qui essaie d'accéder à une nouvelle app
• La réceptionniste est l'app dans laquelle vous vous connectez
• Alice (la personne de confiance à l'intérieur) est Google (ou Apple, ou quel que soit le fournisseur)
• Le badge visiteur est le token que l'app reçoit

Voici le flux réel :

1. Vous cliquez sur "Se connecter avec Google" sur la nouvelle app
2. L'app vous envoie vers la page de connexion de Google
3. Vous vous connectez avec vos identifiants Google (l'app ne voit jamais votre mot de passe Google)
4. Google demande : "Cette app veut accéder à votre nom et email. Autoriser ?"
5. Vous cliquez sur "Autoriser"
6. Google envoie un token à l'app
7. L'app utilise ce token pour obtenir votre nom et email auprès de Google

Le point clé : la nouvelle app ne voit jamais votre mot de passe Google. Elle reçoit uniquement un token limité que Google a émis. Et vous pouvez révoquer ce token à tout moment dans les paramètres de votre compte Google.

Pourquoi OAuth est important pour les PMs

Si vous construisez un produit qui permet aux utilisateurs de se connecter, vous discuterez probablement d'OAuth avec votre équipe technique. Voici les conversations que vous pourriez avoir :

"Est-ce qu'on devrait supporter Se connecter avec Google ?" Presque toujours oui pour les produits grand public. Ça réduit la friction à l'inscription. Les utilisateurs n'ont pas besoin de créer encore un mot de passe.

"Quelles permissions doit-on demander ?" OAuth permet de demander des scopes spécifiques : juste l'email ? La photo de profil ? L'accès au calendrier ? Demandez le minimum nécessaire. Les utilisateurs s'inquiètent quand une app demande trop.

Points clés

• Les tokens identifient une session utilisateur, pas juste une app. Ils sont créés quand un utilisateur se connecte.
• Le flux de connexion : envoyer les identifiants, recevoir un token, inclure le token dans les requêtes suivantes.
• Les access tokens expirent rapidement (minutes à heures). Les refresh tokens permettent à l'app d'en obtenir de nouveaux silencieusement.
• OAuth ("Se connecter avec Google") permet aux utilisateurs de se connecter via un fournisseur de confiance sans partager leur mot de passe avec la nouvelle app.
• L'app reçoit un token limité, pas le vrai mot de passe de l'utilisateur. L'utilisateur peut révoquer l'accès à tout moment.