OAuth : utiliser des données sur plusieurs plateformes

Nous utilisons aujourd’hui un grand nombre de sites Internet, de programmes et d’applications mobiles afin de rendre notre vie privée et professionnelle plus facile et plus pratique. Au vu de cette vaste palette d’outils, il est devenu naturel pour de nombreuses personnes d’utiliser les contenus d’un site Internet (par exemple Instagram) sur un autre (par exemple Facebook) et donc d’intervenir sur de multiples plates-formes. Mais ces processus entraînant le transfert d’un grand nombre de données personnelles, on est en droit de se demander de quelle sécurité bénéficie notre vie privée. Le protocole d’autorisation OAuth a pour vocation de réduire le risque d’une utilisation abusive et non autorisée des données. Peut-il se targuer d’y parvenir ?

OAuth, abréviation de « Open Authorization », est un protocole standard ouvert permettant une autorisation API sécurisée. Spécifique au domaine de la programmation, le terme API (abréviation de « Application Programming Interface ») désigne dans ce contexte une interface agissant comme un transmetteur de données entre les différentes applications, interfaces utilisateur ou pages Web. Afin d’éviter tout risque d’interception de ces données par des tiers et leur utilisation abusive, une autorisation des transferts de données effectués entre ces API est par conséquent nécessaire.

Par exemple : pour pouvoir poster un élément sur Facebook au nom de l’utilisateur (c’est-à-dire accéder à l’API de Facebook), une application doit présenter une autorisation dudit utilisateur. De même, une application a besoin de l’autorisation d’un utilisateur pour pouvoir extraire les informations de son profil sur un autre service. Grâce à OAuth, l’utilisateur peut accorder une telle autorisation sans avoir à communiquer à l’application autorisée son nom d’utilisateur ou son mot de passe. Il conserve ainsi le contrôle total sur ses données.

Ainsi, les prestataires tels que Twitter, Facebook et Google peuvent utiliser OAuth pour concevoir leurs produits et leurs prestations 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 entreprises utilisant OAuth comme standard afin de déléguer les autorisations pour leurs services.

OAuth2, qu’on appelle également « OAuth 2.0 » et qui n’est pas rétrocompatible 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 exclusivement le nouveau protocole en tant que standard d’autorisation. Il sert de base à la couche d’authentification OpenID Connect (OIDC).

En principe, le but de OAuth2 est le même que celui de son prédécesseur : offrir davantage de flexibilité ainsi qu’une plus grande sécurité à l’utilisateur à l’aide de l’autorisation API. De nombreuses faiblesses du protocole initial – qui rendaient le codage et l’implémentation de plus en plus compliqués à mesure que les systèmes de Facebook, Twitter et d’autres exploitants d’API devenaient plus complexes – ont toutefois été corrigées.

Outre une terminologie entièrement révisée, la principale nouveauté de OAuth2 est que – contrairement à son prédécesseur – il n’exige plus de signatures cryptographiques pour chaque communication de machine à machine lors du déroulement du protocole, ce qui facilite grandement l’application et l’extension du protocole. Mais cela implique également une sécurisation moindre d’un point de vue technique, un changement qui a valu à OAuth2 quelques critiques.

Open Authorization 2.0 a par ailleurs été complété par des processus d’autorisation plus fortement différenciés (Grant Types) et a amélioré la performance du protocole. Pour y parvenir, les développeurs ont fait en sorte qu’OAuth2 ne demande plus les données d’accès de l’utilisateur (Resource Owner) à chaque étape de la communication, mais uniquement à la première autorisation de l’application 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 facilement les autorisations accordées. Sous OAuth2, l’utilisateur peut par ailleurs décider personnellement quelles autorisations (scope) il accorde à une application.

Lorsqu’il s’agit de procédure Single Sign-on (SSO), OAuth est rapidement associé à OpenID et SAML. Même si ces trois concepts servent à vérifier les identités des utilisateurs de façon fiable, il existe de grandes différences entre les trois.

OpenID (abréviation de « Open Identification ») est un protocole ouvert : lorsqu’un utilisateur crée un compte OpenID, il peut se connecter à d’autres services et applications à l’aide d’un jeton également compatible 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’utilisateur.

Par conséquent, et contrairement à OAuth, OpenID n’est pas un standard d’autorisation, mais d’authentification. Les deux protocoles sont toutefois étroitement 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 différents types d’applications (clients) de vérifier l’identité de l’utilisateur à l’aide d’une authentification via un serveur d’autorisation et de collecter des informations de base sur ce dernier. En contrepartie, le protocole a été complété avec toutes les fonctionnalités nécessaires à une connexion et à une procédure Single Sign-on. OpenID Connect peut par ailleurs être étendu avec des fonctionnalités optionnelles 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 propriétés des deux concepts précédents. En effet, ce langage est aussi bien un standard pour l’authentification que pour l’autorisation. Dans son fonctionnement, SAML est similaire à OpenID et est également utilisé pour les procédures Single Sign-on.

Pour comprendre le fonctionnement du protocole OAuth2, il faut avoir une vue d’ensemble des rôles et des processus d’autorisation qui y sont définis.

OAuth2 distingue quatre rôles :

• Resource Owner (ou : user, utilisateur) : une entité qui accorde à un client l’accès à ses données protégées (ou : ressources).
• Resource Server (ou : service) : un serveur sur lequel sont enregistrées les données protégées du Resource Owner.
• Client (ou : tiers, Third-Party) : une application de bureau, Web ou mobile souhaitant accéder aux données protégées du Resource Owner.
• Authorization Server : un serveur qui authentifie le Resource Owner et génère un jeton d’accès d’une durée limitée pour un domaine d’application (scope) qu’il a défini. L’Authorization Server et le Resource Server sont en pratique souvent exploités conjointement, auquel cas ils sont nommés serveurs OAuth.

On opère par ailleurs une distinction entre quatre processus d’autorisation prédéfinis (Grant Types) utilisés dans différents cas d’application :

• Code d’autorisation (Authorization Code) : le Client demande au Resource Owner de se connecter auprès d’un Authorization Server. Le Resource Owner est ensuite redirigé vers le Client avec un code d’autorisation. En échange de ce code, l’Authorization Server génère un jeton d’accès pour le Client.
• Autorisation implicite (Implicit Authorization) : ce processus d’autorisation est fortement similaire à l’autorisation via un code d’autorisation, mais est moins complexe puisque l’Authorization Server génère directement le jeton d’accès.
• Déblocage du mot de passe par le Resource Owner (Resource Owner Password Credentials) : dans ce cadre, le Resource Owner confie directement 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.
• Autorisation Client (Client Credentials) : ce processus d’autorisation particulièrement simple est utilisé lorsque le Client souhaite accéder à des données n’ayant pas de propriétaire ou pour lesquelles aucune autorisation n’est nécessaire.

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 rafraîchissement, d’une durée limitée plus longue, afin de demander un nouveau jeton d’accès à l’Authorization Server. Il n’est alors pas nécessaire de renouveler l’autorisation du Resource Owner.

Les réseaux sociaux Pinterest et Facebook nous fournissent des exemples concrets du déroulement du protocole OAuth2. Pinterest offre par exemple la possibilité 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 informations qui y sont renseignées. Pour des raisons de sécurité des données évidentes, il n’est toutefois pas conseillé de communiquer le nom d’utilisateur 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 fonctionnalités du compte Facebook. OAuth2 est utilisé pour permettre malgré tout à Pinterest d’accéder aux données nécessaires du compte Facebook :

1. L’utilisateur se connecte tout d’abord à son compte Pinterest puis se rend dans les paramètres de son profil utilisateur.
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’utilisateur de se connecter à Facebook et de valider l’application Pinterest. Cette action tient lieu d’autorisation.
4. Pinterest demande un jeton d’accès à l’Authorization 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écouverte d’une faille de sécurité dans le déroulement de l’authentification du protocole a démontré qu’un système conçu pour la protection des données personnelles 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’utilisateurs Gmail ont ainsi été victimes d’une attaque de phishing basée sur OAuth. Un Email fallacieux les invitait à donner leur autorisation via une interface factice afin de permettre à une application nommée « Google Apps » d’accéder à leurs données de compte.

Le développement de la nouvelle version OAuth2 devait donc non seulement faciliter l’implémentation 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’approbation des développeurs 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 publication. Dans un article sur son blog hueniverse.com daté du 26 juillet 2012, il expliquait les raisons de cette décision et caractérisait 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éveloppement du nouveau protocole avait été déterminé par des débats constants entre les développeurs et les entreprises concernées (notamment Yahoo!, Google, Twitter, mais aussi la Deutsche Bank). Les points litigieux finissaient par être ignorés au profit, généralement, d’intérêts économiques. 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 représenter une norme strictement définie, OAuth2 est tout au plus un framework que l’on peut adapter et étendre à volonté. OAuth2 aurait ainsi perdu son interopérabilité, ce qui implique que différentes implémentations d’OAuth2 ne seraient pas nécessairement compatibles entre elles.

E. Hammer-Lahav regrette également que l’on ait opté pour une implémentation simplifiée (par exemple en abandonnant les signatures), ce qui entraînerait un défaut de sécurité. Pour pouvoir programmer une application sécurisée supportant OAuth2, les développeurs doivent faire preuve d’un grand niveau d’expertise. Il est donc probable que les applications peu sécurisées se multiplient sur Internet à l’avenir. D’après E. Hammer-Lahav, des erreurs d’implémentation seraient inévitables au vu des spécifications incomplètes et excessivement complexes.

Les craintes de E. Hammer-Lahav étaient fondées, tout du moins en partie : en 2016, un groupe de chercheurs de l’université 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 chercheurs ont toutefois estimé que le protocole était relativement sécurisé à condition qu’il soit correctement mis en œuvre. Selon ses propres informations, l’équipe de OAuth2 a déjà corrigé ces points faibles. Pour de nombreux experts informatiques, le rapport de recherche a toutefois été l’occasion de se pencher davantage sur l’utilisation sécurisée de OAuth 2.0 dans des articles spécialisés.