OAuth : utiliser des données sur plusieurs pla­te­formes

Nous utilisons aujourd’hui un grand nombre de sites Internet, de pro­grammes et d’ap­pli­ca­tions mobiles afin de rendre notre vie privée et pro­fes­sion­nelle plus facile et plus pratique. Au vu de cette vaste palette d’outils, il est devenu naturel pour de nom­breuses personnes d’utiliser les contenus d’un site Internet (par exemple Instagram) sur un autre (par exemple Facebook) et donc d’in­ter­ve­nir sur de multiples plates-formes. Mais ces processus en­traî­nant le transfert d’un grand nombre de données per­son­nelles, on est en droit de se demander de quelle sécurité bénéficie notre vie privée. Le protocole d’au­to­ri­sa­tion OAuth a pour vocation de réduire le risque d’une uti­li­sa­tion abusive et non autorisée des données. Peut-il se targuer d’y parvenir ?

OAuth, abré­via­tion de « Open Au­tho­ri­za­tion », est un protocole standard ouvert per­met­tant une au­to­ri­sa­tion API sécurisée. Spé­ci­fique au domaine de la pro­gram­ma­tion, le terme API (abré­via­tion de « Ap­pli­ca­tion Pro­gram­ming Interface ») désigne dans ce contexte une interface agissant comme un trans­met­teur de données entre les dif­fé­rentes ap­pli­ca­tions, in­ter­faces uti­li­sa­teur ou pages Web. Afin d’éviter tout risque d’in­ter­cep­tion de ces données par des tiers et leur uti­li­sa­tion abusive, une au­to­ri­sa­tion des trans­ferts de données effectués entre ces API est par con­sé­quent né­ces­saire.

Par exemple : pour pouvoir poster un élément sur Facebook au nom de l’uti­li­sa­teur (c’est-à-dire accéder à l’API de Facebook), une ap­pli­ca­tion doit présenter une au­to­ri­sa­tion dudit uti­li­sa­teur. De même, une ap­pli­ca­tion a besoin de l’au­to­ri­sa­tion d’un uti­li­sa­teur pour pouvoir extraire les in­for­ma­tions de son profil sur un autre service. Grâce à OAuth, l’uti­li­sa­teur peut accorder une telle au­to­ri­sa­tion sans avoir à com­mu­ni­quer à l’ap­pli­ca­tion autorisée son nom d’uti­li­sa­teur ou son mot de passe. Il conserve ainsi le contrôle total sur ses données.

Ainsi, les pres­ta­taires tels que Twitter, Facebook et Google peuvent utiliser OAuth pour concevoir leurs produits et leurs pres­ta­tions de façon plus flexible et plus sécurisée, notamment à l’aide des solutions Single Sign-On. Amazon et Microsoft font également partie des grandes en­tre­prises utilisant OAuth comme standard afin de déléguer les au­to­ri­sa­tions pour leurs services.

OAuth2, qu’on appelle également « OAuth 2.0 » et qui n’est pas ré­tro­com­pa­tible avec la version pré­cé­dente, a été publié en octobre 2012 comme une refonte totale de OAuth et l’a aujourd’hui largement remplacé. La Graph API de Facebook, par exemple, utilise désormais ex­clu­si­ve­ment le nouveau protocole en tant que standard d’au­to­ri­sa­tion. Il sert de base à la couche d’au­then­ti­fi­ca­tion OpenID Connect (OIDC).

En principe, le but de OAuth2 est le même que celui de son pré­dé­ces­seur : offrir davantage de flexi­bi­lité ainsi qu’une plus grande sécurité à l’uti­li­sa­teur à l’aide de l’au­to­ri­sa­tion API. De nom­breuses fai­blesses du protocole initial – qui rendaient le codage et l’im­plé­men­ta­tion de plus en plus com­pli­qués à mesure que les systèmes de Facebook, Twitter et d’autres ex­ploi­tants d’API de­ve­naient plus complexes – ont toutefois été corrigées.

Outre une ter­mi­no­lo­gie en­tiè­re­ment révisée, la prin­ci­pale nouveauté de OAuth2 est que – con­trai­re­ment à son pré­dé­ces­seur – il n’exige plus de sig­na­tures cryp­to­gra­phiques pour chaque com­mu­ni­ca­tion de machine à machine lors du dé­rou­le­ment du protocole, ce qui facilite gran­de­ment l’ap­pli­ca­tion et l’extension du protocole. Mais cela implique également une sé­cu­ri­sa­tion moindre d’un point de vue technique, un chan­ge­ment qui a valu à OAuth2 quelques critiques.

Open Au­tho­ri­za­tion 2.0 a par ailleurs été complété par des processus d’au­to­ri­sa­tion plus fortement dif­fé­ren­ciés (Grant Types) et a amélioré la per­for­mance du protocole. Pour y parvenir, les dé­ve­lop­peurs ont fait en sorte qu’OAuth2 ne demande plus les données d’accès de l’uti­li­sa­teur (Resource Owner) à chaque étape de la com­mu­ni­ca­tion, mais uni­que­ment à la première au­to­ri­sa­tion de l’ap­pli­ca­tion concernée (Client). Autre nouveauté notable : les jetons d’accès disposent d’une validité plus courte, ce qui permet à un service (Resource Server) de révoquer plus fa­ci­le­ment les au­to­ri­sa­tions accordées. Sous OAuth2, l’uti­li­sa­teur peut par ailleurs décider per­son­nel­le­ment quelles au­to­ri­sa­tions (scope) il accorde à une ap­pli­ca­tion.

Lorsqu’il s’agit de procédure Single Sign-on (SSO), OAuth est ra­pi­de­ment associé à OpenID et SAML. Même si ces trois concepts servent à vérifier les identités des uti­li­sa­teurs de façon fiable, il existe de grandes dif­fé­rences entre les trois.

OpenID (abré­via­tion de « Open Iden­ti­fi­ca­tion ») est un protocole ouvert : lorsqu’un uti­li­sa­teur crée un compte OpenID, il peut se connecter à d’autres services et ap­pli­ca­tions à l’aide d’un jeton également com­pa­tible avec OpenID. Le bouton « Se connecter avec Google », que l’on trouve aujourd’hui sur de nombreux sites Internet, en est un bon exemple puisqu’il autorise une procédure Single Sign-on sur le compte Google de l’uti­li­sa­teur.

Par con­sé­quent, et con­trai­re­ment à OAuth, OpenID n’est pas un standard d’au­to­ri­sa­tion, mais d’au­then­ti­fi­ca­tion. Les deux pro­to­coles sont toutefois étroi­te­ment liés depuis 2014 : la nouvelle version de OpenID, appelée OpenID Connect (OIDC), est en effet basée sur OAuth 2.0. OAuth2 permet aux dif­fé­rents types d’ap­pli­ca­tions (clients) de vérifier l’identité de l’uti­li­sa­teur à l’aide d’une au­then­ti­fi­ca­tion via un serveur d’au­to­ri­sa­tion et de collecter des in­for­ma­tions de base sur ce dernier. En con­tre­par­tie, le protocole a été complété avec toutes les fonc­tion­na­li­tés né­ces­saires à une connexion et à une procédure Single Sign-on. OpenID Connect peut par ailleurs être étendu avec des fonc­tion­na­li­tés op­tion­nelles telles qu’une gestion de session et le cryptage des données d’identité.

Étant ouvert et basé sur XML, le « Security Assertion Markup Language » (abrégé en : SAML) réunit en quelque sorte les pro­prié­tés des deux concepts pré­cé­dents. En effet, ce langage est aussi bien un standard pour l’au­then­ti­fi­ca­tion que pour l’au­to­ri­sa­tion. Dans son fonc­tion­ne­ment, SAML est similaire à OpenID et est également utilisé pour les pro­cé­dures Single Sign-on.

Pour com­prendre le fonc­tion­ne­ment du protocole OAuth2, il faut avoir une vue d’ensemble des rôles et des processus d’au­to­ri­sa­tion qui y sont définis.

OAuth2 distingue quatre rôles :

• Resource Owner (ou : user, uti­li­sa­teur) : une entité qui accorde à un client l’accès à ses données protégées (ou : res­sources).
• Resource Server (ou : service) : un serveur sur lequel sont en­re­gis­trées les données protégées du Resource Owner.
• Client (ou : tiers, Third-Party) : une ap­pli­ca­tion de bureau, Web ou mobile sou­hai­tant accéder aux données protégées du Resource Owner.
• Au­tho­ri­za­tion Server : un serveur qui au­then­ti­fie le Resource Owner et génère un jeton d’accès d’une durée limitée pour un domaine d’ap­pli­ca­tion (scope) qu’il a défini. L’Au­tho­ri­za­tion Server et le Resource Server sont en pratique souvent exploités con­join­te­ment, auquel cas ils sont nommés serveurs OAuth.

On opère par ailleurs une dis­tinc­tion entre quatre processus d’au­to­ri­sa­tion pré­dé­fi­nis (Grant Types) utilisés dans dif­fé­rents cas d’ap­pli­ca­tion :

• Code d’au­to­ri­sa­tion (Au­tho­ri­za­tion Code) : le Client demande au Resource Owner de se connecter auprès d’un Au­tho­ri­za­tion Server. Le Resource Owner est ensuite redirigé vers le Client avec un code d’au­to­ri­sa­tion. En échange de ce code, l’Au­tho­ri­za­tion Server génère un jeton d’accès pour le Client.
• Au­to­ri­sa­tion implicite (Implicit Au­tho­ri­za­tion) : ce processus d’au­to­ri­sa­tion est fortement similaire à l’au­to­ri­sa­tion via un code d’au­to­ri­sa­tion, mais est moins complexe puisque l’Au­tho­ri­za­tion Server génère di­rec­te­ment le jeton d’accès.
• Déblocage du mot de passe par le Resource Owner (Resource Owner Password Cre­den­tials) : dans ce cadre, le Resource Owner confie di­rec­te­ment au Client ses données d’accès, ce qui va certes à l’encontre du principe de base de OAuth, mais permet un effort moindre pour le Resource Owner.
• Au­to­ri­sa­tion Client (Client Cre­den­tials) : ce processus d’au­to­ri­sa­tion par­ti­cu­liè­re­ment simple est utilisé lorsque le Client souhaite accéder à des données n’ayant pas de pro­prié­taire ou pour les­quelles aucune au­to­ri­sa­tion n’est né­ces­saire.

Si le Client a de nouveau besoin, à l’avenir, d’accéder aux données protégées du Resource Owner, il peut utiliser un jeton de ra­fraî­chis­se­ment, d’une durée limitée plus longue, afin de demander un nouveau jeton d’accès à l’Au­tho­ri­za­tion Server. Il n’est alors pas né­ces­saire de re­nou­ve­ler l’au­to­ri­sa­tion du Resource Owner.

Les réseaux sociaux Pinterest et Facebook nous four­nis­sent des exemples concrets du dé­rou­le­ment du protocole OAuth2. Pinterest offre par exemple la pos­si­bi­lité d’importer des contacts depuis une liste d’amis Facebook. Pinterest a besoin pour cela d’avoir accès au compte en question et aux in­for­ma­tions qui y sont ren­seig­nées. Pour des raisons de sécurité des données évidentes, il n’est toutefois pas conseillé de com­mu­ni­quer le nom d’uti­li­sa­teur et le mot de passe du compte Facebook à Pinterest. Dans un tel cas, Pinterest pourrait en effet accéder à tout moment et de façon illimitée aux données et aux fonc­tion­na­li­tés du compte Facebook. OAuth2 est utilisé pour permettre malgré tout à Pinterest d’accéder aux données né­ces­saires du compte Facebook :

1. L’uti­li­sa­teur se connecte tout d’abord à son compte Pinterest puis se rend dans les pa­ra­mètres de son profil uti­li­sa­teur.
2. Dans la barre de menu « Réseaux sociaux », on déplace alors le bouton à côté de « Facebook » sur « Oui ».
3. Pinterest demande à l’uti­li­sa­teur de se connecter à Facebook et de valider l’ap­pli­ca­tion Pinterest. Cette action tient lieu d’au­to­ri­sa­tion.
4. Pinterest demande un jeton d’accès à l’Au­tho­ri­za­tion Server de Facebook et l’utilise pour accéder aux données protégées sur le Resource Server.
5. Désormais, les amis Facebook importés seront également affichés dans le compte Pinterest.

En avril 2009, la dé­cou­verte d’une faille de sécurité dans le dé­rou­le­ment de l’au­then­ti­fi­ca­tion du protocole a démontré qu’un système conçu pour la pro­tec­tion des données per­son­nelles comme OAuth n’était pas fiable à 100 %. Comme pour de nombreux autres systèmes de ce type, le phishing est un risque permanent : entre avril et mai 2017 par exemple, un million d’uti­li­sa­teurs Gmail ont ainsi été victimes d’une attaque de phishing basée sur OAuth. Un Email fal­la­cieux les invitait à donner leur au­to­ri­sa­tion via une interface factice afin de permettre à une ap­pli­ca­tion nommée « Google Apps » d’accéder à leurs données de compte.

Le dé­ve­lop­pe­ment de la nouvelle version OAuth2 devait donc non seulement faciliter l’im­plé­men­ta­tion de ce protocole de plus en plus complexe, mais aussi augmenter sa sécurité. En octobre 2012, les efforts réalisés dans ce cadre ont abouti à un résultat qui n’a toutefois pas reçu l’ap­pro­ba­tion des dé­ve­lop­peurs qui avaient contribué à la version initiale de OAuth. Eran Hammer-Lahav, le rédacteur principal de OAuth2, était le seul à avoir travaillé sur l’ancien OAuth et il ne tarda pas à prendre ses distances avec le nouveau projet, trois mois seulement après sa pu­bli­ca­tion. Dans un article sur son blog hue­ni­verse.com daté du 26 juillet 2012, il ex­pli­quait les raisons de cette décision et ca­rac­té­ri­sait OAuth 2.0 de « descente aux enfers » dans l’intitulé même de l’article.

Que s’était-il passé ? D'après E. Hammer-Lahav, le dé­ve­lop­pe­ment du nouveau protocole avait été déterminé par des débats constants entre les dé­ve­lop­peurs et les en­tre­prises con­cer­nées (notamment Yahoo!, Google, Twitter, mais aussi la Deutsche Bank). Les points litigieux fi­nis­saient par être ignorés au profit, gé­né­ra­le­ment, d’intérêts éco­no­miques. D’après E. Hammer-Lahav, le résultat est un protocole qui n’en porte aujourd’hui que le nom. En effet, plutôt que de re­pré­sen­ter une norme stric­te­ment définie, OAuth2 est tout au plus un framework que l’on peut adapter et étendre à volonté. OAuth2 aurait ainsi perdu son in­te­ro­pé­ra­bi­lité, ce qui implique que dif­fé­rentes im­plé­men­ta­tions d’OAuth2 ne seraient pas né­ces­sai­re­ment com­pa­tibles entre elles.

E. Hammer-Lahav regrette également que l’on ait opté pour une im­plé­men­ta­tion sim­pli­fiée (par exemple en aban­don­nant les sig­na­tures), ce qui en­traî­ne­rait un défaut de sécurité. Pour pouvoir pro­gram­mer une ap­pli­ca­tion sécurisée sup­por­tant OAuth2, les dé­ve­lop­peurs doivent faire preuve d’un grand niveau d’expertise. Il est donc probable que les ap­pli­ca­tions peu sé­cu­ri­sées se mul­ti­plient sur Internet à l’avenir. D’après E. Hammer-Lahav, des erreurs d’im­plé­men­ta­tion seraient iné­vi­tables au vu des spé­ci­fi­ca­tions in­com­plètes et ex­ces­si­ve­ment complexes.

Les craintes de E. Hammer-Lahav étaient fondées, tout du moins en partie : en 2016, un groupe de cher­cheurs de l’uni­ver­sité de Trèves s’est penché pour la première fois sur la sécurité du protocole OAuth2 et a découvert deux failles de sécurité. L’une d’entre elles a permis des attaques de l’homme du milieu. Sur le principe, les cher­cheurs ont toutefois estimé que le protocole était re­la­ti­ve­ment sécurisé à condition qu’il soit cor­rec­te­ment mis en œuvre. Selon ses propres in­for­ma­tions, l’équipe de OAuth2 a déjà corrigé ces points faibles. Pour de nombreux experts in­for­ma­tiques, le rapport de recherche a toutefois été l’occasion de se pencher davantage sur l’uti­li­sa­tion sécurisée de OAuth 2.0 dans des articles spé­cia­li­sés.