OAuth
En 2006, Blaine Cook travaillait sur l'API de Twitter et se heurtait à un problème qui devenait récurrent chez les développeurs web. Il cherchait un moyen de connecter Twitter à Flickr, le service de partage de photos. La seule solution disponible était de demander aux utilisateurs de confier leurs identifiants Flickr à Twitter. Une aberration en matière de sécurité, mais c'était la norme à l'époque.
Cette impasse technique a poussé Cook et d'autres développeurs de grandes plateformes web à se réunir. Google avait AuthSub, Yahoo utilisait BBAuth, AOL proposait OpenAuth, et Flickr disposait de sa propre API. Chacun bricolait sa solution dans son coin. Il fallait sortir de ce morcellement. En octobre 2007, leur collaboration aboutit à OAuth 1.0, un protocole ouvert destiné à résoudre ce casse-tête : comment autoriser une application tierce à accéder aux données d'un utilisateur sans jamais manipuler son mot de passe ?
Le mécanisme repose sur un principe simple mais efficace. Imaginons un service d'impression en ligne qui veut accéder aux photos stockées sur un autre site. Au lieu de réclamer les identifiants du compte photos, il obtient un jeton d'accès spécifique, limité aux seules opérations nécessaires. L'utilisateur garde le contrôle : il autorise explicitement l'accès depuis une interface sécurisée du site hébergeant ses photos. Le service d'impression ne connaît jamais le mot de passe.
Les premières failles de sécurité se sont manifestées, et en juin 2009, OAuth 1.0a corrigeait des vulnérabilités permettant des usurpations d'identité. Cette révision a clarifié des zones d'ombre du protocole initial et renforcé les protections contre les attaques. L'année suivante, en avril 2010, l'IETF publiait OAuth 1.0 comme RFC 5849, lui conférant un statut de spécification technique officielle.
Le protocole définit trois acteurs : le propriétaire de la ressource (l'utilisateur), le client (l'application qui demande l'accès) et le serveur d'autorisation. L'application obtient d'abord des identifiants temporaires. Elle redirige ensuite l'utilisateur vers une page d'autorisation où celui-ci examine les permissions demandées. Après validation, l'application reçoit un jeton qu'elle utilisera pour ses requêtes futures. À aucun moment elle ne touche aux identifiants de l'utilisateur.
La sécurité s'appuie sur des garde-fous. Chaque requête doit être signée avec une clé secrète. Le protocole intègre des jetons uniques (nonces) et des timestamps pour bloquer toute tentative de réutilisation malveillante. Les concepteurs ont anticipé les attaques par détournement de session, par rejeu, ou par usurpation.
Facebook, Google, Microsoft et Twitter ont adopté OAuth. Cette adhésion massive des géants du web a créé un écosystème d'applications interconnectées. Des bibliothèques sont apparues dans tous les langages de programmation courants, rendant l'intégration plus accessible.
Mais OAuth 1.0 montrait ses limites. La complexité de l'implémentation, notamment pour la signature cryptographique des requêtes, décourageait les développeurs. Les applications mobiles natives, de plus en plus nombreuses, posaient des problèmes non prévus au départ. Ces contraintes ont motivé une refonte complète du protocole avec OAuth 2.0.
Le protocole OAuth a établi le standard de l'autorisation déléguée sur le web. Il a introduit des concepts désormais centraux : le consentement explicite de l'utilisateur, la limitation stricte des privilèges accordés, la séparation nette entre authentification et autorisation.
OAuth a aussi joué un rôle éducatif. Développeurs et utilisateurs ont pris conscience des enjeux autour de la protection des données personnelles. Le protocole a démontré qu'il était possible de créer des services interconnectés sans sacrifier la sécurité. Cette prise de conscience a accompagné l'évolution des réglementations sur la vie privée.
Par ailleurs, les architectures modernes portent la marque d'OAuth. OpenID Connect s'appuie sur ses fondations pour ajouter une couche d'authentification standardisée. Les API REST et les microservices reprennent ses principes architecturaux. Les objets connectés et les systèmes d'identités décentralisées explorent de nouvelles pistes en partant des bases posées par OAuth.
La communauté continue d'adapter le protocole aux nouveaux usages. Les retours d'expérience des déploiements à grande échelle alimentent les réflexions sur ses évolutions futures. OAuth reste un pilier de la sécurité web, près de vingt ans après sa création.