Module 1 — Qu'est-ce qu'OAuth ?
Bonne lecture et bon apprentissage ! Junior TSAFACK – 12/09/2026 Temps de lecture estimé : 6 minutes
Le problème : le partage de mot de passe
Section titled “Le problème : le partage de mot de passe”Imaginez une application de retouche photo qui propose : « Importez vos photos depuis Google Photos ». Sans OAuth, une seule solution existerait : donner votre mot de passe Google à cette application. Elle pourrait alors :
- Lire absolument tous vos emails, vos contacts, votre agenda — bien plus que vos photos.
- Garder ce mot de passe indéfiniment, sans que vous puissiez révoquer uniquement cet accès.
- Si elle est piratée, exposer votre compte Google complet, pas juste vos photos.
C’est exactement le problème qu’un ingénieur de Twitter (aujourd’hui X) a rencontré en 2006 en développant une fonctionnalité d’import de contacts — et qui a mené, avec des ingénieurs de Google et d’autres, à la création d’OAuth (Open Authorization).
L’idée : déléguer une autorisation, pas s’authentifier
Section titled “L’idée : déléguer une autorisation, pas s’authentifier”Sans OAuth : "Voici mon mot de passe Google, fais ce que tu veux avec mon compte."Avec OAuth : "Voici un jeton qui te permet UNIQUEMENT de lire mes photos, valable 1h, que je peux révoquer à tout moment sans changer mon mot de passe."OAuth répond à une question précise : comment un utilisateur peut-il autoriser une application tierce à agir en son nom, auprès d’un service qu’il utilise déjà, sans jamais lui révéler son mot de passe ?
Les 3 acteurs (version simplifiée)
Section titled “Les 3 acteurs (version simplifiée)”Pour bien démarrer, gardons une version simplifiée à 3 rôles — nous verrons le vocabulaire officiel exact au Module 2 :
| Rôle simplifié | Qui c’est | Exemple |
|---|---|---|
| User | Vous, le propriétaire du compte | Vous, sur l’app de retouche photo |
| Server | L’application qui veut accéder à vos données | L’app de retouche photo |
| IdP (Identity Provider) | Le service qui connaît réellement votre identité et vos données |
Le dialogue qu’on peut imaginer entre le Server et Google (IdP) résume tout OAuth :
Server : « Je veux que l’utilisateur se connecte, mais je ne veux pas gérer encore un mot de passe. » Google : « J’ai déjà ses données. Quand un utilisateur veut se connecter, envoie-le moi. Je peux valider ses identifiants. » Server : « Parfait ! Valide juste son identité et donne-moi quelques infos (email…). » Google : « D’accord. Ensuite, en fonction de ces infos, tu décides ce à quoi tu donnes accès… » Server : « Comme ça, l’utilisateur n’a plus besoin d’un mot de passe de plus ! » Google : « Et si l’utilisateur donne son consentement, tu peux aussi agir sur son compte. »
C’est ce principe — déléguer la vérification d’identité et l’octroi d’accès à un tiers de confiance — qui permet à un seul compte Google, GitHub ou Microsoft de donner accès à des dizaines de services différents (Foo, Bar, Qux…) sans jamais leur communiquer le moindre mot de passe.
Un peu d’histoire : 1.0 → 2.0
Section titled “Un peu d’histoire : 1.0 → 2.0”| Version | Ce qu’elle visait |
|---|---|
| OAuth 1.0 (2010) | Protocole conçu uniquement pour les navigateurs web. Chaque requête devait être signée cryptographiquement (complexe à implémenter correctement). |
| OAuth 2.0 (2012, RFC 6749) | Refonte complète pour couvrir les applications web, applications non-navigateur, applications mobiles, applications de bureau, et les API. Repose sur HTTPS plutôt que sur des signatures par requête — plus simple, mais qui déplace la responsabilité de la sécurité vers le bon usage du protocole (voir Module 5). |
OAuth 2.0 est la version quasi-universellement utilisée aujourd’hui — c’est celle que couvre tout le reste de ce cours.