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 moindred’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 :
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 :
Une fois la terminologie ci-dessus connue, il est alors facile de comprendre le déroulement des différents protocoles. Voici un exemple de ce à quoi ressemble le déroulement d’un protocole :
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 :
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.
La vie en ligne serait si simple si l’on pouvait saisir une seule fois nos données d’accès, les enregistrer et rester connecté, au lieu de retenir une douzaine de mots de passe ! C’est chose faite avec le SSO, toujours plus populaire parmi les utilisateurs. Mais la commodité et la prétendue sécurité des données s’accompagnent de certains inconvénients sur lesquels les fournisseurs se gardent bien...
Les mots de passe ont depuis longtemps cessé d’offrir une protection suffisante pour naviguer sur Internet. Ils sont faciles à déchiffrer, aisément manipulables et sont donc difficiles à garder. Le World Wide Web Consortium a développé un nouveau standard en collaboration avec la FIDO Alliance. WebAuthn est destiné à faciliter et à sécuriser l’inscription et la connexion sur les réseaux sociaux ou...
JSON Web Token (JWT) est un standard ouvert pour l’authentification flexible des utilisateurs. Les données sont échangées entre les interlocuteurs en toute sécurité et peuvent être vérifiées. Une signature numérique assure en outre la fiabilité des données. Découvrez ici ce qu’est un JWT, comment cela fonctionne et pourquoi il est judicieux d’utiliser cette technologie.
Les organisations limitent les autorisations d’accès aux systèmes afin de protéger les données sensibles des accès et des modifications non autorisés. L’attribution d’autorisations individuelles par utilisateur nécessite toutefois une maintenance considérable et s’avère sujette aux erreurs. Avec le Role Based Access Control, abrégé RBAC, les autorisations sont attribuées à l’aide de rôles...
Des offres exceptionnelles sur l'hébergement Web, les serveurs virtuels, le stockage en ligne, les outils de collaboration et bien plus.
Valables jusqu'au 7/12/2020.
