OAuth

Qu’est-ce qu’OAuth ?

OAuth, abréviation de « open authorization », est un protocole ouvert couramment utilisé pour permettre aux sites web ou aux applications d’accéder aux informations des utilisateurs stockées sur d’autres sites, sans partager de mots de passe. Avec OAuth, une personne peut permettre de manière sélective et sécurisée à deux sites de communiquer directement afin de faciliter une tâche particulière. OAuth donne la permission ou l’autorisation d’accéder aux données, ce qui est différent de l’authentification d’une identité (comme lorsqu’un utilisateur se connecte à un service).

OAuth peut être utilisé dans des situations impliquant un navigateur web, une application mobile ou un appareil de l’Internet des objets (IdO). Il est destiné à simplifier des tâches telles que le déplacement de fichiers, la recherche d’amis sur un site de médias sociaux ou le changement de paramètres sur un thermostat domestique. Le service qui reçoit la permission d’accéder aux données d’un utilisateur peut se voir octroyer un accès limité à certaines données et des capacités variées (par exemple, lecture seule ou lecture et modification). OAuth est parfois confondu avec la fonctionnalité de connexion tierce qui permet à un utilisateur de se connecter à un site en utilisant les identifiants Google ou Facebook. La connexion tierce, appelée « open ID connect » (OIDC), est juste une application spécifique d’OAuth. Cet article se concentre sur OAuth, mais abordera également l’application OIDC des capacités d’OAuth.

À quoi ressemble OAuth ?

Voici un exemple d’OAuth en action. Lorsque vous créez un compte sur un service de médias sociaux comme LinkedIn, l’un des premiers éléments que le site ou l’application vous demandera est si vous souhaitez connecter votre carnet d’adresses pour que LinkedIn puisse vous suggérer d’autres personnes à ajouter à votre réseau. Si vous déclarez que votre carnet d’adresses est dans Gmail, LinkedIn vous donnera un portail pour vous connecter à Google. Si vous procédez à la connexion à Google et autorisez cette connexion au carnet d’adresses, LinkedIn collectera alors les adresses e-mail de votre carnet d’adresses et recherchera ces adresses dans la base de données des utilisateurs enregistrés de LinkedIn. Cela vous évite de devoir rechercher des connexions, car vos informations peuvent être directement importées depuis Gmail.

Cette autorisation reste en place jusqu’à ce que vous demandiez à Google de la révoquer ou jusqu’à sa date d’expiration. Si vous ajoutez des adresses e-mail à votre compte Gmail et souhaitez que LinkedIn lance une nouvelle recherche, vous n’aurez pas besoin de réautoriser l’accès de LinkedIn au carnet d’adresses Gmail.

Cet exemple illustre quelques avantages d’OAuth :

• Vous pouvez connecter ces services sans avoir à partager vos informations de connexion Google avec LinkedIn. Ainsi, vos informations d’identification sont stockées dans un nombre réduit d’endroits et sont donc moins exposées au risque d’une violation de données.
• Le processus est simplifié pour vous. LinkedIn et Gmail gèrent le partage des données avec un effort minimal de votre part.
• Vous pouvez révoquer la permission de LinkedIn à tout moment.
• LinkedIn n’obtient accès qu’aux adresses e-mail de votre carnet d’adresses, et à rien d’autre dans votre carnet ou dans votre compte e-mail en général.

Comment fonctionne OAuth ?

Plusieurs parties sont impliquées, ainsi que plusieurs étapes pour configurer un partage de données avec OAuth. Certaines de ces étapes sont visibles, tandis que d’autres se déroulent en arrière-plan (c’est-à-dire directement entre les deux services). Les étapes exactes peuvent varier selon l’utilisation d’OAuth, mais en utilisant l’exemple LinkedIn/Google, nous pouvons expliquer à peu près OAuth à travers les parties impliquées et les étapes réelles de configuration.

Les parties impliquées

• Propriétaire de la ressource : L’entité, généralement une personne, qui souhaite permettre à un service d’accéder aux données d’un autre service.
• Client : L’application ou le service qui souhaite accéder à certaines données ou effectuer certaines tâches pour le propriétaire de la ressource. Dans notre exemple, LinkedIn est le client car il souhaite accéder à un carnet d’adresses stocké dans Gmail.
• Serveur d’autorisation : Le service (dans ce cas Google) qui reçoit une demande d’accès du client, et vérifie la permission avec le propriétaire de la ressource. Le serveur d’autorisation prépare le jeton d’accès (comme une clé) que le client utilisera pour accéder aux données demandées (adresses e-mail) maintenant et à l’avenir.
• Serveur de ressource : L’entité qui possède réellement les données (adresses e-mail) que le propriétaire de la ressource souhaite donner au client. Dans certains cas, c’est la même entité que le serveur d’autorisation ; cependant, dans d’autres, cela peut être différent (dans notre exemple, le serveur de ressource est Gmail).

Les étapes pour mettre en place un accord OAuth

Ce qui suit est un flux de code d’autorisation général qui représente ce qui se passe avec OAuth. Notez qu’il existe de nombreux autres flux, légèrement différents, qui ont également été créés pour différents scénarios.

1. Vous allez sur le site de LinkedIn et demandez à LinkedIn de rechercher des personnes que vous pourriez connaître.
   • (Le propriétaire de la ressource initie le processus OAuth en indiquant à l’application cliente qu’il veut faire quelque chose avec ses données.)
2. LinkedIn informe Google que vous souhaitez partager votre carnet d’adresses Gmail avec LinkedIn.
   • (Le client envoie une demande au serveur d’autorisation en disant que le propriétaire de la ressource veut que le client accède à certaines données.)
3. Google vérifie qu’il traite avec LinkedIn et non un imposteur, et quelles données sont demandées.
   • (La demande d’autorisation contient la portée de la demande et quelles données sont demandées ; les adresses e-mail ; ce que le client est autorisé à faire avec les données ; télécharger uniquement ; et où renvoyer la demande d’autorisation ; comme une URL telle que linkedin.com/callback. La demande d’autorisation contient également un code que le serveur d’autorisation et le client utilisent pour vérifier qu’ils sont bien les uns et les autres durant tout processus d’autorisation.)
4. Google renvoie un jeton à LinkedIn.
   • (Le serveur d’autorisation donne au client un jeton de requête ; un paquet numérique qui inclut une redéfinition de la portée et un secret spécifique à cet arrangement.)
5. LinkedIn affiche un écran où vous pouvez vous connecter à Google et confirmer que vous souhaitez partager des adresses e-mail avec LinkedIn.
   • (Le propriétaire de la ressource voit un écran d’autorisation qui lui demande de vérifier s’il veut permettre au client l’accès spécifié aux données. Lorsque le propriétaire de la ressource valide la demande, la validation envoie également le jeton de requête, avec la portée et le secret, comme preuve que rien n’a été détourné durant le processus de validation.)
6. Google enregistre que vous avez accordé à LinkedIn la permission de télécharger des adresses e-mail depuis votre compte Gmail.
   • (Le serveur d’autorisation reçoit la validation avec le jeton de requête, vérifie que tout est conforme aux attentes, et marque dans ses registres que le propriétaire de la ressource a confirmé la demande.)
7. LinkedIn confirme que Gmail a tout ce dont il a besoin et demande l’accès aux adresses e-mail enregistrées dans le carnet d’adresses. Gmail répond avec une clé que LinkedIn peut utiliser pour accéder aux adresses e-mail pendant une certaine période.
   • (Le client peut désormais soumettre formellement le jeton de requête avec une demande d’accès au serveur de ressource. Le serveur de ressource voit que le jeton de requête a été validé et délivre un jeton d’accès au client. Le jeton d’accès détaille quelles données peuvent être consultées, quelles autorisations ont été accordées concernant ces données, et combien de temps le jeton d’accès est valide. Le jeton ne contient rien qui identifie spécifiquement le propriétaire de la ressource, seulement quelles données peuvent être consultées.)
8. Lorsque vous demandez à LinkedIn de lancer une nouvelle recherche d’amis, LinkedIn peut accéder à votre carnet d’adresses sans avoir à répéter toutes les étapes ci-dessus.
   • (Le client peut désormais utiliser le jeton d’accès pour accéder directement aux données spécifiquement autorisées sur le serveur de ressources sans avoir besoin de confirmation répétée par le propriétaire de la ressource.)

En quoi l’OIDC est-il différent de l’OAuth ?

L’OIDC, ou connexion tierce, est un protocole d’authentification basé sur le cadre OAuth. La différence entre les deux n’est pas toujours évidente. L’OIDC vous permet de vous connecter à un service, comme Spotify, en utilisant des identifiants d’un autre service, comme Google. La différence clé est que l’OIDC vous authentifie, tandis que l’OAuth donne l’autorisation d’effectuer des actions avec vos données en votre nom. Un processus OAuth aboutit à un jeton d’accès contenant des autorisations d’accès aux données. Un processus OIDC aboutit à un jeton d’accès jumelé à un jeton d’identité qui contient l’état de vérification de l’authentification de l’utilisateur (en gros, que vous êtes bien qui vous prétendez être), et peut-être des informations sur l’utilisateur, comme le nom ou l’e-mail.

Lorsque le service que l’utilisateur souhaite accéder (Spotify) reçoit le jeton d’identité du service d’authentification (Google), il sait que l’authentification est réussie. Le processus OIDC ne confère au service accédé aucun privilège concernant les données de l’utilisateur sur le service d’authentification. Un autre résultat de cette transaction est que le service d’authentification confirme également l’authenticité du service accédé.

Risques pour la sécurité et la confidentialité avec l’OAuth et l’OIDC

OAuth et OIDC offrent tous deux une meilleure sécurité. Les protocoles OAuth permettent de ne pas partager les identifiants entre les services et de réduire l’exposition aux violations de données ; ils donnent également à l’individu un contrôle plus affiné sur la manière dont les autres utilisent ses données. L’avantage d’utiliser une connexion tierce (OIDC) lorsque c’est possible est qu’elle réduit le nombre de connexions à suivre ; cela peut se traduire par de meilleures habitudes de sécurité (comme l’utilisation de mots de passe forts et uniques).

Mais comme pour toute avancée en matière de sécurité, les risques évoluent également en réponse. Avec le processus OAuth, les pirates possédant des identifiants de connexion volés peuvent injecter une fausse URL dans le processus, détournant les jetons destinés au client vers les sites web des pirates. Les pirates peuvent alors utiliser les jetons détournés pour accéder illégalement aux données d’un utilisateur.

Avec l’OIDC, les pirates peuvent tromper un individu en utilisant un faux écran de connexion tierce afin de collecter l’identifiant et le mot de passe de l’utilisateur. En ce qui concerne la confidentialité, utiliser une connexion tierce donne à Google ou Facebook plus de données à collecter sur votre activité, puisqu’ils peuvent désormais surveiller votre utilisation de ces applications et sites web auxquels vous vous connectez.