29 juillet 2024
L’autorisation ouverte (OAuth) est un cadre d’autorisation standard ouvert qui permet aux applications d’accéder aux ressources protégées d’un utilisateur final (photos, calendriers, publications sur les médias sociaux, etc.), ceci sans avoir besoin de l’identifiant ou du mot de passe du compte de l’utilisateur.
Les sites web et les applications tierces qui proposent aux utilisateurs les options « Se connecter avec Google » ou « Autoriser l’accès aux informations de votre compte » sont des cas d’utilisation courants de l’OAuth. Le protocole OAuth permet aux utilisateurs d’accorder facilement à ces applications l’accès aux données de leur compte sans partager leurs identifiants.
Outre les applications web, l’OAuth peut également donner un accès aux ressources à diverses entités : API, applications côté serveur, applications natives des systèmes d’exploitation, applications mobiles et certains appareils (téléviseurs intelligents et appareils électroménagers). Dans certains cas, aucun utilisateur humain n’est impliqué, car l’OAuth peut autoriser l’accès aux applications au nom d’une organisation ou d’un compte professionnel.
Renforcez vos renseignements de sécurité
Gardez une longueur d’avance sur les menaces grâce à l’actualité et aux réflexions sur la sécurité, l’IA et bien plus encore, dans la newsletter hebdomadaire Think.
En empêchant l’accès aux données de connexion et en limitant l’accès à d’autres informations sensibles, l’OAuth offre d’importants avantages en matière de gestion des accès pour les utilisateurs, les développeurs et les entreprises. Elle permet également aux applications d’accéder plus facilement aux informations de compte nécessaires, sans les vulnérabilités de sécurité liées au partage des identifiants de l’utilisateur.
En simplifiant l’accès sécurisé, OAuth peut aider les entreprises à relever certains de leurs plus grands défis en matière de sécurité. Par exemple, une étude de l’IBM Institute for Business Value a révélé que 52 % des dirigeants voient dans la complexité le principal obstacle à leurs opérations de cybersécurité.
Une petite équipe de développeurs de logiciels a lancé OAuth 1.0 en 2007. Cette première version du protocole a été conçue comme une alternative à l’authentification web, qui obligeait les utilisateurs à partager leur nom d’utilisateur et leur mot de passe avec des services tiers. Cependant, OAuth 1.0 ne fournissait des flux d’autorisation que pour les sites web.
En 2012, l’Internet Engineering Task Force (IETF) a publié OAuth 2.0 sous la forme des RFC 6749 et 6750. Une RFC (en anglais « Request for Comments ») est un document de l’IETF qui décrit les protocoles de communication internet. La RFC 6749 est le cadre de base d’OAuth 2.0, et la RFC 6750 définit la façon dont le cadre utilise les jetons d’accès.
Cette version mise à jour d’OAuth a étendu le protocole au-delà des navigateurs web et a inclus des fonctionnalités d’autorisation pour les applications, les API et les appareils. OAuth 2.0 a remplacé OAuth 1.0 et constitue désormais la norme du secteur.
Contrairement à d’autres cadres qui reposent sur des noms d’utilisateur et des mots de passe, l’OAuth est un protocole d’autorisation basé sur des jetons d’accès. Les jetons d’accès sont des informations qui déterminent les ressources spécifiques auxquelles une application est autorisée à accéder. Le protocole OAuth définit la façon dont chaque composant d’un processus de demande d’autorisation approuve, définit et gère les jetons d’accès.
Les jetons OAuth utilisent généralement la norme JSON Web Token (JWT) en raison de sa capacité à transmettre des données en toute sécurité.
Les principaux composants du cadre OAuth sont :
- Le propriétaire de la ressource
- Le serveur de ressources
- Client
- Le serveur d’autorisation
- Portée
Il s’agit de l’utilisateur final propriétaire du compte auquel l’application cherche à accéder, comme un compte Facebook ou Google. Le propriétaire de la ressource donne son consentement pour que l’application accède à certaines ressources protégées de ce compte, comme des photos ou des données personnelles. Dans certains cas, le propriétaire de la ressource peut être une entreprise ou un compte professionnel.
Il s’agit du serveur qui stocke les ressources protégées pour le compte de l’utilisateur. Le serveur de ressources accepte et valide les jetons OAuth qu’il reçoit du client, puis fournit les données utilisateur que le propriétaire de la ressource a consenti à libérer.
Le client est l’application, le site web, l’API ou l’appareil qui demande l’accès. Il demande l’autorisation au serveur d’autorisation en présentant un identifiant client. Ensuite, une fois que le propriétaire de la ressource a donné son consentement, le client reçoit un jeton d’accès qu’il peut utiliser pour accéder aux ressources protégées sur le serveur de ressources.
Il s’agit du serveur principal qui gère le protocole OAuth. Il utilise deux points de terminaison pour accorder l’accès au serveur de ressources.
Le point de terminaison d’autorisation invite le propriétaire de la ressource à donner son consentement pour des ressources protégées spécifiques. Le point de terminaison du jeton reçoit ensuite la demande de jeton du client OAuth et génère de nouveaux jetons d’accès qui accordent l’accès aux ressources.
Les champs d’application sont les paramètres d’accès aux ressources protégées sur le serveur de ressources.
Par exemple, le propriétaire de la ressource peut être invité à donner son consentement pour un accès à des données telles que des e-mails, des fichiers ou des photos. Le champ d’application limite l’accès des clients à ces seuls éléments.
Exemple de flux d’OAuth
Voici un aperçu de la manière dont un flux d’OAuth est susceptible de fonctionner :
- Jim (le propriétaire de la ressource) souhaite autoriser un site de réseau social (le client) à accéder à ses contacts e-mail (la ressource).
- Le serveur d’autorisation du compte e-mail invite Jim à consentir à cet accès.
- Après avoir reçu le consentement de Jim, le serveur d’autorisation fournit un jeton d’accès au site de média social
- Le site de média social présente le jeton d’accès au serveur de ressources qui stocke les informations du compte e-mail de Jim.
- Le serveur de ressources reconnaît le jeton d’accès et autorise le site de média social à accéder aux contacts e-mail de Jim. Étant donné que le jeton d’accès inclut le champ d’application du consentement de Jim, le site de réseau social ne peut accéder à aucune autre donnée du compte de Jim.
La procédure consistant à fournir un jeton d’accès à une application est appelée une attribution d’autorisation ou un flux d’autorisation. Il existe différents types d’attribution et de flux d’OAuth qui peuvent être utilisés pour différents types d’applications, d’appareils ou d’API, tels que :
- Le code d’autorisation
- La clé de vérification pour l’échange de code (« Proof Key for Code Exchange » ou PKCE)
- Les identifiants du client
- L’attribution implicite
- L’actualisation du jeton
Le code d’autorisation
Ce type d’attribution est généralement utilisé pour les applications web et mobiles. Dans un flux de code d’autorisation, le serveur d’autorisation fournit un code d’autorisation à usage unique au client. Le client peut ensuite échanger ce code d’autorisation contre un jeton d’accès auprès du point de terminaison du serveur d’autorisation.
La clé de vérification pour l’échange de code (« Proof Key for Code Exchange » ou PKCE)
Ce flux ajoute une sécurité supplémentaire à l’attribution du code d’autorisation, le but étant de protéger les applications contre les attaques par injection de code. Ces types d’attaques peuvent inciter les applications à exécuter un code malveillant qui modifie leur fonctionnement.
La clé de vérification pour l’échange de code (PKCE) ajoute un « secret client » qui authentifie le client auprès du serveur d’autorisation avant qu’un jeton d’accès ne soit émis. Comme seul le client légitime possède le secret, les acteurs malveillants ne peuvent pas se faire passer pour le client et introduire un code malveillant.
Les identifiants du client
Ce type d’attribution est conçu pour les situations dans lesquelles aucun utilisateur humain n’est impliqué (processus automatisés, interactions entre machines et microservices).
Les applications ont accès aux ressources système dont elles ont besoin pour exécuter des fonctions, mais n’ont pas accès aux ressources des utilisateurs finaux. Par exemple, l’attribution d’identifiants client peut permettre à une application météorologique d’accéder à une API pour récupérer les données relatives aux dernières prévisions.
L’attribution implicite
Ce type d’attribution simplifie le flux des applications web écrites en JavaScript. Contrairement à l’attribution d’un code d’autorisation, le flux implicite ne nécessite pas de code d’autorisation avant l’émission d’un jeton d’accès.
Au lieu de cela, une fois que l’utilisateur a donné son consentement, le jeton d’accès est inclus dans l’identifiant uniforme de ressource (URI) de redirection qui renvoie l’utilisateur à l’application demandant l’accès. L’application obtient le jeton d’accès à partir de l’URI.
L’actualisation du jeton
Si un jeton d’accès a expiré, ce type d’attribution fournit à l’application un jeton d’actualisation qui peut être échangé contre un nouveau jeton d’accès. Sans jeton d’actualisation, l’utilisateur final doit à nouveau donner son consentement pour que l’application reçoive un nouveau jeton d’accès.
La différence fondamentale est que la connexion unique (SSO) est un protocole d’authentification des utilisateurs, alors que l’OAuth est un protocole d’autorisation.
La SSO fait souvent appel à un fournisseur d’identité (IdP) et au Security Assertion Markup Language (SAML), qui est basé sur l’Extensible Markup Language (XML), pour authentifier les identités numériques des utilisateurs au moyen de noms d’utilisateur et de mots de passe.
L’OAuth n’authentifie pas les utilisateurs, elle les autorise à accéder aux ressources du système. Les solutions SSO utilisent parfois l’OAuth pour permettre aux utilisateurs authentifiés d’accéder facilement aux applications et aux services de l’entreprise.
L’OpenID Connect (OIDC) est un protocole d’authentification basé sur OAuth 2.0. Si l’on combine les deux, OpenID Connect peut vérifier l’identité d’un utilisateur, puis l’OAuth peut autoriser cet utilisateur à accéder à des ressources et à des services.