Qu’est-ce que l’OAuth (Open Authorization) ?

OAuth (Open Authorization) est un protocole qui permet à un utilisateur d’autoriser une application tierce à accéder à ses données sans partager le mot de passe de son compte. Il permet aux utilisateurs de s’authentifier et d’autoriser des applications tierces à accéder à leurs données et ressources stockées sur un serveur donné — telles que leurs informations de compte, leurs photos et leurs documents — sans révéler leurs identifiants de connexion.

L’Open Authorization est également utilisé pour les connexions en un clic, permettant aux utilisateurs de s’identifier auprès d’un service web sans avoir à saisir leur nom d’utilisateur et leur mot de passe à chaque fois.

Lorsqu’un service Web se connecte à un autre, les services fonctionnent avec le protocole OAuth pour garantir une interaction sûre qui ne demande pas aux utilisateurs de partager leurs mots de passe.

Le partage des mots de passe n’est jamais recommandé, quelle que soit l’application. C’est pourquoi de grandes entreprises technologiques telles que Google et Twitter ont introduit une solution appelée OAuth.

En 2010, Google a proposé aux petits éditeurs d’applications de créer des services qui utilisent les informations du compte Google au lieu de demander aux utilisateurs de partager leurs mots de passe Google avec un tiers.

Au lieu de stocker les données sensibles des mots de passe et de maintenir la sécurité des comptes des utilisateurs, un tiers pouvait utiliser le système de Google pour demander aux utilisateurs de s’authentifier et de stocker un jeton d’accès. Le jeton d’accès stocke l’autorisation du compte Google, et l’application tierce utilise ensuite le jeton OAuth pour accéder à un ensemble défini de données du compte Google.

Le protocole OAuth a connu plusieurs itérations, les dernières améliorations majeures datant de 2012. Plusieurs autres grandes entreprises technologiques offrent désormais l’intégration OAuth aux développeurs tiers. Amazon, Netflix, PayPal, Microsoft, LinkedIn, Facebook et bien d’autres permettent aux développeurs tiers d’intégrer leurs données de compte d’utilisateur dans des applications utilisant OAuth.

Avant l’OAuth, chaque service Web avait des informations d’identification distinctes pour un compte utilisateur. Les services ne pouvaient pas partager leurs données, sauf s’ils proposaient une API permettant de transmettre les données entre eux.

Même avec une API, le passage des mots de passe entre les services constitue une faille de sécurité, exposant les données privées de plusieurs services si un seul est violé.

L’OAuth permet aux utilisateurs de donner à des applications tierces l’accès à leurs comptes pour un large éventail de fonctionnalités. Il peut s’agir, par exemple, d’utiliser les données du calendrier pour faciliter la planification, de stocker les paramètres des applications dans le cloud ou même d’analyser leurs listes de lecture de musique pour obtenir de nouvelles recommandations.

Les mots de passe ne sont plus nécessaires pour l’autorisation, et les utilisateurs peuvent révoquer l’accès à tout moment. Les développeurs d’applications tierces stockent un jeton d’accès pour récupérer les données autorisées, qui doit être stocké de manière sécurisée, sans exposer les informations d’identification de l’utilisateur.

Trois entités sont impliquées dans une transaction OAuth réussie :

• L’utilisateur (la personne ou l’organisation autorisant l’accès à ses données).
• Le fournisseur de services OAuth (l’application ou le service qui stocke les données et les informations d’identification de l’utilisateur)
• Le consommateur (l’application qui demande l’accès aux données de l’utilisateur).

L’OAuth utilise un flux de travail défini pour garantir la sécurité des données de l’utilisateur et simplifier les demandes pour le consommateur.

Tout d’abord, l’application demandant l’accès (consommateur) demande un jeton d’accès OAuth au fournisseur de services. S’ils ne sont pas déjà connectés au fournisseur de services, les utilisateurs sont invités à le faire. Le fournisseur de services énumère ensuite les types de données auxquels l’application du consommateur cherche à accéder et demande à l’utilisateur d’approuver ou de refuser l’accès.

Si l’utilisateur accepte, le fournisseur de services envoie alors un jeton d’accès au consommateur, qui le stocke pour les futures demandes d’accès. Une fois validé, le jeton d’accès est utilisé dans toutes les demandes d’accès aux données de l’utilisateur (dans le cadre des autorisations accordées par l’utilisateur).

Les jetons d’accès expirent, c’est pourquoi les fournisseurs de services offrent aux développeurs un moyen de rafraîchir les jetons d’accès pour les futures demandes. La durée de validité d’un jeton d’accès est fixée par le fournisseur de services et dépend donc des protocoles de sécurité du fournisseur de services.

Le jeton d’accès doit être stocké de manière sécurisée car il peut être utilisé par n’importe qui pour obtenir les données de l’utilisateur et exécuter des fonctions en son nom.

Si les utilisateurs décident de révoquer l’accès, ils peuvent le faire par l’intermédiaire du fournisseur de services. Une fois l’accès révoqué, le consommateur doit demander à l’utilisateur de s’authentifier à nouveau pour obtenir toutes les données stockées sur l’application du fournisseur de services.

Si le consommateur est victime d’une violation de données au cours de laquelle les jetons d’accès sont divulgués, le fournisseur de services peut invalider de manière proactive tous les jetons d’accès afin de protéger les données des utilisateurs.

Lorsque les consommateurs utilisent OAuth, le fournisseur de services ne fournit un accès autorisé aux données d’un utilisateur qu’après le consentement de ce dernier.

OAuth est un moyen de partager des données en utilisant un jeton d’autorisation fourni par le consommateur après que l’utilisateur ait vérifié ses informations d’identification. OpenID est distinct d’OAuth, mais les deux sont utilisés ensemble.

L’authentification unique (SSO) est une stratégie de sécurité commune qui utilise un fournisseur pour authentifier les utilisateurs dans plusieurs services. OpenID est l’un des plus anciens protocoles SSO, introduit en 2005 pour authentifier les utilisateurs de LiveJournal.

Il a fait l’objet de quelques mises à jour, mais il était considéré comme trop difficile à mettre en œuvre par rapport aux autres méthodes de l’époque, principalement Facebook Connect. Facebook étant une marque bien connue, la plupart des développeurs ont opté pour Facebook Connect afin que les utilisateurs se sentent plus à l’aise pour s’authentifier dans leurs applications.

En 2014, OpenID a remanié son code et a ensuite été intégré à OAuth. Désormais, OAuth utilise OpenID comme couche d’authentification, et OAuth s’occupe de la couche d’autorisation. Le processus est transparent pour l’utilisateur, mais les consommateurs peuvent plus facilement intégrer OAuth pour à la fois authentifier les utilisateurs et obtenir l’accès aux données de leur compte.

Un ancien produit similaire à OAuth est le Security Assertion Markup Language basé sur XML. La principale différence entre SAML et OAuth est que SAML effectue à la fois l’authentification et l’autorisation. OAuth utilise OpenID comme couche d’authentification, mais ne gère pas l’authentification à part entière. Les applications qui utilisent SAML n’ont pas besoin d’autres services pour assurer l’authentification.

Une autre différence entre les deux protocoles est le langage utilisé pour transmettre les données entre les services. SAML utilise XML ; OAuth utilise JSON, le format préféré pour les transferts de données.

La plupart des services de données fonctionnent principalement avec JSON, ce qui rend OAuth plus facile à intégrer pour la plupart des entreprises.

Comme tout autre protocole, OAuth a évolué et s’est amélioré au fil du temps. OAuth 2.0 a supplanté OAuth 1.0 (qui n’est plus sécurisé), de sorte que la plupart des fournisseurs de services n’autorisent que l’accès à OAuth 2.0.

OAuth 1.0 est plus facile à utiliser et présente un flux de travail plus simple à certains égards. Mais il n’est plus considéré comme un moyen sûr de travailler avec des comptes d’utilisateur.

OAuth 2.0 a ajouté deux étapes au processus d’autorisation. Il autorise le HTTPS et les secrets signés, de sorte que les jetons n’ont plus besoin d’être chiffrés sur les terminaux (appareils des utilisateurs).

Le protocole HTTPS chiffre les jetons d’accès en transit, bien que certains services qui stockent des informations personnelles identifiables (PII) ou d’autres données sensibles chiffrent encore les données au repos.

L’une des critiques formulées à l’encontre d’OAuth 2.0 est qu’il autorise les transferts de données sur des canaux non chiffrés. Les développeurs sont donc responsables du maintien du chiffrement TLS/SSL sur les canaux.

Pour qu’un développeur puisse profiter d’OAuth 2.0, le fournisseur de services doit l’avoir implémenté sur son système. Plusieurs grands sites de médias sociaux utilisent l’OAuth 2.0 pour intégrer leur plateforme à d’autres applications. Il s’agit d’un avantage marketing qui aide les propriétaires de plateformes à faire connaître leurs produits.

Depuis que Google a lancé OAuth 2.0, de nombreuses applications l’utilisent comme fournisseur de SSO et comme service fournissant des informations de base sur les utilisateurs.

Dans un flux de travail d’OAuth 2.0 simple, le consommateur propose un lien vers “Se connecter avec Google” comme option pour créer un compte. Si l’utilisateur est déjà authentifié, Google affiche une liste de ressources et de données auxquelles le consommateur aurait accès si l’utilisateur accepte.

L’utilisateur peut autoriser ou refuser la demande d’autorisation du consommateur. Si l’utilisateur refuse, le consommateur ne peut pas accéder aux données de l’utilisateur. Si l’utilisateur autorise la demande de données, le fournisseur de services donne au consommateur un jeton d’accès. Le jeton d’accès fournit une autorisation uniquement pour les données énumérées dans la demande initiale.

Pour la plupart des grandes plateformes, une application grand public doit être vérifiée au préalable par le fournisseur de services avant d’accéder à certaines données. En général, le consommateur indique les données dont il a besoin pour fonctionner et la manière dont ces données seront utilisées. Le fournisseur de services peut autoriser ou refuser la demande de manière préventive.

L’OAuth est également utilisé pour intégrer une plateforme dans un autre service. Supposons que vous ayez une application qui fonctionne directement avec le produit Google tel que Gmail. Pour lire directement les e-mails de vos utilisateurs, vous avez besoin de l’autorisation de l’utilisateur. Google utilise l’OAuth pour permettre à votre application d’interagir avec le compte Gmail de l’utilisateur.

Pour utiliser le service Gmail de Google dans votre application, vous spécifiez les données nécessaires au fonctionnement de l’application ; les utilisateurs doivent ensuite autoriser l’application à y accéder.

L’OAuth est sûr s’il est déployé correctement. Le fournisseur de services doit s’assurer que le consommateur est autorisé à accéder aux données ; le consommateur doit utiliser TLS/SSL pour établir une connexion sécurisée et transférer les données sous forme cryptée.

Le fournisseur de services peut s’assurer que les données sont transmises en toute sécurité en demandant aux consommateurs d’utiliser des connexions cryptées et en rejetant tout canal non crypté.

Bien que plus sûr que le partage d’informations d’identification, l’Open Authorization n’est pas sans risque. Voici quelques pièges de sécurité auxquels les organisations doivent faire attention lorsqu’elles autorisent les utilisateurs à connecter des applications externes à leurs comptes en utilisant OAuth.

OAuth et risques de phishing

La menace de phishing est une préoccupation majeure avec l’OAuth. Les attaquants utilisent souvent des liens vers des pages Web demandant aux utilisateurs de saisir des informations d’identification pour s’authentifier sur leurs comptes.

La page ressemble à une page officielle similaire à celle d’un service utilisant l’OAuth. Mais au lieu de s’authentifier auprès d’un service officiel, les utilisateurs saisissent leurs informations d’identification sur le site de phishing d’un attaquant. Les utilisateurs doivent vérifier l’adresse indiquée dans le popup du navigateur d’authentification pour s’assurer que le site est légitime.

Dans une campagne de phishing que nous avons découverte, les attaquants ont eu accès aux informations d’identification des utilisateurs de Microsoft en modifiant les paramètres de la chaîne de requête de l’URL pour rediriger les utilisateurs vers un site Web de vol d’informations d’identification.

La page de phishing affichait un message d’autorisation Microsoft usurpé qui semblait familier à la plupart des utilisateurs. La page invite les utilisateurs à se connecter à leur compte Microsoft, mais au lieu d’authentifier les utilisateurs, elle donne aux attaquants les informations d’identification du compte Microsoft.

Ces informations d’identification peuvent être utilisées pour prendre le contrôle de comptes Microsoft, obtenir des données d’utilisateurs ou détourner des comptes sur des services distincts où les utilisateurs ont réutilisé ces informations d’identification.

Autorisations trop larges

Lorsque les utilisateurs installent et autorisent des applications via l’OAuth, ils cliquent souvent sur “accepter” sans examiner de près la portée des autorisations. Toute application disposant d’autorisations d’accès étendues constitue un risque potentiel pour la sécurité de votre organisation.

Les applications tierces peuvent être facilement exploitées. Les attaquants peuvent utiliser l’accès OAuth pour compromettre et détourner des comptes cloud. Tant que le jeton OAuth n’est pas explicitement révoqué, l’attaquant dispose d’un accès permanent au compte et aux données de l’utilisateur, même si ce dernier change le mot de passe du compte cloud ou utilise une authentification à deux facteurs (2FA).

Nos recherches ont révélé que de nombreuses applications OAuth pour Office 365 ont des niveaux élevés de permissions. Voici un échantillon de nos conclusions :

• 30 % des locataires disposent d’apps telles que MailMerge365 avec la permission “Envoyer du courrier pour le compte d’autres personnes”.
• 30 % des locataires ont des applications telles que TypeApp avec l’autorisation “Gérer la configuration d’Exchange”.
• 70 % des locataires ont en moyenne neuf applications qui utilisent la permission “Envoyer du courrier en tant qu’utilisateur” (comme Task in A Box).
• Les locataires de Microsoft 365 ont en moyenne 34 applications utilisant la permission “Accéder aux données de l’utilisateur à tout moment” (comme c’est le cas avec OneSync).
• Les locataires de Google Workspace disposant d’apps tierces dans la catégorie “jeux” ont en moyenne 10 jeux.

Applications OAuth malveillantes

Certaines applications et leurs demandes d’autorisation OAuth sont ouvertement malveillantes. Par exemple, nos chercheurs ont suivi une campagne d’attaque appelée OiVaVoii qui publie des applications malveillantes sous l’apparence d’éditeurs d’applications de confiance. Voici comment cela fonctionne :

1. L’attaquant détourne d’abord le compte de l’éditeur d’applications légitime.
2. Se faisant passer pour l’éditeur de confiance, le pirate crée ensuite une application malveillante et envoie des demandes d’autorisation par courrier électronique aux utilisateurs, souvent des cadres supérieurs.
3. Les utilisateurs peu méfiants autorisent l’application, croyant qu’elle provient de l’éditeur de confiance.
4. Une fois les autorisations OAuth accordées, l’attaquant prend le contrôle du compte de l’utilisateur.

Dans le cadre de cette campagne, nous avons détecté des prises de contrôle de comptes appartenant à des PDG, des directeurs généraux, d’anciens membres du conseil d’administration et des présidents. En général, la prise de contrôle est le résultat d’applications OAuth malveillantes qui volent des jetons OAuth ou des informations d’identification.

L’identité apparemment bénigne de l’organisation éditrice a constitué un avantage substantiel, incitant plusieurs victimes peu méfiantes à autoriser les applications malveillantes. Il s’agissait principalement de l’accès aux boîtes aux lettres (lecture et écriture), ce qui leur permettait de :

• Envoyer des e-mails malveillants internes et externes
• Voler des informations précieuses
• Créer des règles de boîte aux lettres pour envoyer des données à l’attaquant et continuer à recevoir les e-mails des utilisateurs après l’attaque.

Figure 1 : Capture d’écran de la demande d’autorisation OAuth d’une application malveillante.

Contactually est une application cloud légitime qui aide les professionnels de l’immobilier à gérer leurs clients et leurs ventes. Mais entre de mauvaises mains, ses puissantes fonctionnalités permettent aux attaquants de se déplacer facilement et latéralement dans l’environnement d’une victime et de maintenir l’accès.

Nous avons détecté une campagne qui a commencé par un phishing par e-mail pour compromettre des utilisateurs dans des organisations ciblées. En utilisant les comptes compromis, les attaquants ont autorisé l’application Contactually et configuré des règles de boîte aux lettres qui redirigeaient ou supprimaient les e-mails. Les règles étaient vraisemblablement conçues pour transférer des courriers précieux vers des comptes externes et supprimer les preuves de l’attaque.

Contactually est un éditeur légitime. L’application dispose d’autorisations étendues, telles que l’accès complet aux contacts des utilisateurs et l’accès en lecture/écriture à leurs e-mails. Mais ces autorisations sont similaires à celles utilisées par n’importe quel client de messagerie et restent dans les limites des fonctions annoncées de l’application.

Néanmoins, si les attaquants ont compromis le compte et autorisent l’application dans votre environnement — comme ils l’ont fait dans la campagne que nous avons détectée — ils peuvent exploiter ces fonctions pour causer des dommages durables.