📖 Module 2 — Le vocabulaire officiel et les 4 types de flux
Bonne lecture et bon apprentissage ! Junior TSAFACK – 12/09/2026 ⏱️ Temps de lecture estimé : 7 minutes
Le Module 1 a utilisé un trio simplifié (User / Server / IdP) pour introduire l’idée. En réalité, la spécification officielle (RFC 6749) distingue 4 rôles, pas 3 — la nuance compte, car elle éclaire une confusion très fréquente.
🎭 Les 4 rôles officiels
Section titled “🎭 Les 4 rôles officiels”| Terme officiel | Rôle | Dans notre exemple (retouche photo) |
|---|---|---|
| Resource Owner | L’utilisateur, propriétaire des données | Vous |
| Client | L’application qui demande l’accès | L’app de retouche photo |
| Authorization Server | Authentifie l’utilisateur et délivre les jetons | Google (le serveur qui gère accounts.google.com) |
| Resource Server | Héberge la donnée protégée et l’expose via une API | Google Photos (l’API qui contient vos photos) |
😲 La nuance qui compte : dans notre exemple, Google joue à la fois le rôle d’Authorization Server et de Resource Server (c’est très courant). Mais ce sont deux responsabilités distinctes : l’un authentifie et délivre des jetons, l’autre vérifie ces jetons et sert la donnée. Dans une architecture à microservices, ce sont fréquemment deux services séparés — un serveur d’authentification central, et plusieurs API qui font simplement confiance à ses jetons.
Resource Owner (vous) │ │ autorise ▼ Client (l'app tierce) ───── demande un jeton ────► Authorization Server │ │ │ délivre un access token │ │ └──────── présente le token ────────► Resource Server ◄──┘ (vérifie le token, retourne la donnée)🔑 Le jeton au centre de tout : l’Access Token
Section titled “🔑 Le jeton au centre de tout : l’Access Token”L’Access Token est ce que l’Authorization Server délivre au Client, et que le Client présente au Resource Server. C’est souvent un JWT (voir le cours dédié) — mais ce n’est pas une obligation : la spécification OAuth ne dit rien sur le format du token, seulement sur comment on l’obtient. Beaucoup de systèmes utilisent une simple chaîne aléatoire opaque, vérifiée par une recherche en base côté Authorization Server.
🚦 Les 4 types de flux (grant types)
Section titled “🚦 Les 4 types de flux (grant types)”Un « grant type » répond à la question : comment le Client obtient-il concrètement son Access Token ? La réponse dépend surtout d’une chose : le Client peut-il garder un secret en sécurité ?
| # | Grant type | Un utilisateur est impliqué ? | Le Client garde-t-il un secret ? | Statut en 2026 |
|---|---|---|---|---|
| 1 | Authorization Code | ✅ Oui | ✅ Oui (serveur backend) ou avec PKCE si non | ✅ Recommandé, quasi-universel |
| 2 | Client Credentials | ❌ Non (machine-à-machine) | ✅ Oui | ✅ Recommandé pour ce cas d’usage |
| 3 | Implicit | ✅ Oui | ❌ Non (SPA sans backend) | ⚠️ Déconseillé depuis OAuth 2.1 |
| 4 | Resource Owner Password Credentials | ✅ Oui | Variable | ⚠️ Déconseillé, à éviter |
1️⃣ Authorization Code — le flux de référence
Section titled “1️⃣ Authorization Code — le flux de référence”Utilisé quand un utilisateur doit se connecter et que le Client dispose d’un backend serveur (ou utilise PKCE, voir Module 3). C’est le flux détaillé pas à pas dans les deux prochains modules — celui que vous rencontrez en cliquant sur « Se connecter avec Google ».
2️⃣ Client Credentials — machine à machine
Section titled “2️⃣ Client Credentials — machine à machine”Aucun utilisateur n’est impliqué : un service s’authentifie directement auprès de l’Authorization Server avec son propre client_id/client_secret, pour agir en son nom propre (par exemple, un job de facturation nocturne qui interroge une API interne). Nous l’exécuterons réellement au Module 4.
3️⃣ Implicit — historique, aujourd’hui déconseillé ⚠️
Section titled “3️⃣ Implicit — historique, aujourd’hui déconseillé ⚠️”Conçu à l’origine pour les applications JavaScript pures (sans backend), ce flux renvoyait l’Access Token directement dans l’URL du navigateur (fragment #access_token=...), sans passer par un code intermédiaire. Problème : une URL peut se retrouver dans l’historique du navigateur, les logs d’un proxy, ou l’en-tête Referer — le token y est exposé bien plus largement qu’on ne le voudrait. La recommandation actuelle (OAuth 2.1) est d’utiliser Authorization Code + PKCE à la place, même pour une application sans backend.
4️⃣ Resource Owner Password Credentials — à éviter ⚠️
Section titled “4️⃣ Resource Owner Password Credentials — à éviter ⚠️”Ce flux demande à l’utilisateur de saisir directement son mot de passe dans le Client, qui l’envoie ensuite à l’Authorization Server pour obtenir un token. Vous remarquez le problème ? C’est exactement ce qu’OAuth a été inventé pour éviter (voir Module 1) ! Ce flux ne se justifie que dans des cas très spécifiques où le Client est totalement digne de confiance (une app officielle du même éditeur que l’Authorization Server) — et même là, il est aujourd’hui déconseillé au profit d’alternatives plus sûres.
🧠 À retenir
Section titled “🧠 À retenir”- 4 rôles officiels : Resource Owner, Client, Authorization Server, Resource Server — souvent simplifiés à tort en 3 (Authorization Server et Resource Server sont deux responsabilités distinctes, même quand le même acteur les assure).
- 4 grant types, mais 2 seulement sont recommandés aujourd’hui : Authorization Code (avec un utilisateur) et Client Credentials (sans utilisateur).
- Implicit et Resource Owner Password Credentials existent encore dans la spec pour des raisons historiques, mais sont à éviter dans tout nouveau projet.