OAuth signifie « Open Authorization » et constitue une norme ouverte pour déléguer de manière sécurisée l’accès à des ressources, sans partager de mots de passe. Il permet à une application d’exécuter des actions ou de demander des données au nom d’un utilisateur. OAuth utilise pour cela des jetons d’accès temporaires émis par un serveur d’autorisation.

Différence entre OAuth 1.0 et OAuth 2.0 ?

OAuth 1.0 était très complexe, avec des signatures cryptographiques pour chaque requête. Cette version était surtout utilisée pour des services web. OAuth 2.0 a simplifié cela avec des jetons émis par un serveur d’autorisation et sécurisés via HTTPS. Outre l’autorisation, OAuth prend désormais en charge l’authentification et convient aux applications mobiles et aux usages IoT.

OAuth

OAuth ?

OAuth signifie Open Authorization et est un protocole standard qui permet d’accorder à une application l’accès à des données ou à des fonctionnalités au sein d’une autre application. OAuth utilise pour cela des jetons numériques, il n’est donc pas nécessaire de partager des noms d’utilisateur et des mots de passe entre ces applications. Cela rend la collaboration plus simple et plus sûre.

Qu’est-ce qu’OAuth ?

Avec OAuth, vous pouvez donc transmettre de manière standardisée des paramètres d’autorisation d’une application ou d’un service à un autre. Cela peut sembler abstrait, mais on peut le comparer à la carte d’accès remise à l’hôtel lors de l’enregistrement. La réception ne vous confie évidemment pas la clé maîtresse de l’établissement. À la place, vous recevez une carte qui contient exactement vos droits. Comme tout client vous pouvez ouvrir la porte d’entrée, vous avez accès à votre propre chambre, et selon votre réservation par exemple à la salle de sport et au parking.

OAuth fait quelque chose de comparable dans les environnements numériques. Un ‘authorization server’ attribue des droits à une application cible au moyen d’un jeton d’accès. L’application à laquelle le jeton est destiné reçoit ainsi des droits sur des données et des fonctions spécifiques accessibles via des API.

Comment fonctionne OAuth ?

Cela s’illustre le mieux par le type d’usage pour lequel OAuth a été conçu à l’origine. À l’ère du cloud, les applications ont souvent besoin de données stockées ailleurs dans le cloud. Ou elles utilisent des fonctionnalités d’autres systèmes. Comment rendre ces données et ces fonctionnalités accessibles à d’autres applications ? Il existe deux approches : la solution conventionnelle avant OAuth, et la solution avec OAuth.

Accès conventionnel aux ressources en ligne sans OAuth

Prenons l’exemple d’un outil en ligne de retouche photo. Vous souhaitez l’utiliser pour modifier les photos que vous stockez sur votre Google Drive. L’application doit donc accéder à votre Google Drive et, à l’époque pré-OAuth, cela se faisait en se connectant directement à votre compte Google depuis l’application via une API. Il fallait alors utiliser votre nom d’utilisateur et votre mot de passe et l’application obtenait l’accès à vos photos, mais aussi à toutes les autres fonctionnalités et données de votre compte Google. Ce n’est pas souhaitable, et c’est précisément pour cela qu’OAuth a été développé.

Accès aux ressources en ligne avec OAuth

Avec OAuth, il n’est plus nécessaire de se connecter à votre compte Google depuis l’application. À la place, vous recevez une notification indiquant que l’application souhaite accéder à vos photos Google Drive et que vous devez vous connecter à votre compte Google pour donner votre consentement.

Lorsque vous vous connectez à votre compte, la question vous est posée automatiquement de savoir si vous autorisez l’application à modifier les photos sur votre Drive. Si vous confirmez cette demande, Google, qui joue ici le rôle de serveur d’autorisation, envoie un jeton d’accès à l’application concernée. Celle-ci obtient alors l’accès à votre compte Google, mais uniquement pour consulter et modifier les photos. Tout autre accès reste bloqué.

Pour l’utilisateur, les scénarios se ressemblent, car dans les deux cas vous vous connectez avec vos identifiants Google. Sans OAuth, cela se fait toutefois à l’intérieur de l’application, ce qui ouvre aussitôt l’accès à l’ensemble de vos données. Avec OAuth, vous vous connectez de manière habituelle à votre compte Google et vous n’accordez à l’application qu’un droit spécifique : consulter et modifier les photos.

Avantages d’OAuth ?

OAuth apporte plusieurs avantages :

Il est possible d’accorder des autorisations à des systèmes sans devoir partager le mot de passe de quiconque. Il existe ainsi une séparation claire entre l’authentification de l’utilisateur et les autorisations accordées.
Un mécanisme d’autorisation granulaire est disponible. Lorsque des identifiants personnels sont utilisés, une application reçoit automatiquement l’ensemble des droits de la personne. Avec OAuth, vous pouvez définir des autorisations beaucoup plus spécifiques. Les droits peuvent aussi être révoqués facilement sans devoir modifier le mot de passe.
Un protocole standard peut être utilisé entre différents types de systèmes et d’applications, provenant de divers éditeurs et prestataires.
La gestion des droits d’accès est simplifiée, car des droits détaillés pour plusieurs systèmes peuvent être définis à partir d’un point central.

Exemples d’OAuth en pratique

Les exemples d’utilisation d’OAuth sont nombreux, mais il est surtout utile de distinguer deux types de scénarios. Nous en présentons un exemple pour chacun.

Type d’application 1 : Autorisations déléguées

Le scénario de retouche photo mentionné plus haut illustre un cas où OAuth est uniquement utilisé pour déléguer des droits spécifiques à d’autres applications. Dans l’application de retouche photo, l’utilisateur voit par exemple l’invite suivante :

“Cette application souhaite accéder aux photos de votre Google Drive. Connectez-vous à Google et autorisez l’utilisation de vos photos.”

En vous connectant ensuite à votre compte Google et en confirmant la demande, vous donnez cette autorisation. L’application reçoit alors un jeton d’accès avec des droits exacts, sans rien savoir de l’utilisateur. Aucune donnée d’identité n’est partagée, il s’agit uniquement d’un accès technique à des ressources en ligne.

Type d’application 2 : Authentification déléguée (par exemple Single Sign-On)

OAuth est aujourd’hui également utilisé pour prendre en charge des scénarios de Single Sign-On (SSO). Supposons que vous ne souhaitiez pas utiliser l’application de retouche photo ponctuellement, mais ouvrir un compte pour bénéficier de fonctionnalités supplémentaires. L’approche traditionnelle consiste à créer un compte, saisir vos données personnelles et définir un mot de passe. Il existe heureusement des solutions plus simples, par exemple se connecter via Google ou un autre compte de réseau social. Dans ce cas, l’application affiche un message de ce type :

"Cette application souhaite utiliser votre identité pour vous connecter. Connectez-vous à Google et autorisez le partage de votre nom, de votre adresse e-mail et de vos informations de profil."

C’est pratique, car vous n’avez pas à utiliser un nom d’utilisateur et un mot de passe distincts pour ce compte. Dès que vous êtes connecté à Google, vous avez également accès à l’application en tant qu’utilisateur enregistré. Ce mécanisme est disponible avec de nombreux comptes personnels (Google, Microsoft, Facebook, etc.)

Les organisations utilisent intensivement ce type de fonctionnalité SSO. Elles s’appuient sur un fournisseur d’identité tel que Google Workspace, Microsoft Active Directory ou Entra ID. Les fournisseurs IAM comme HelloID disposent également d’un fournisseur d’identité intégré.

Différence entre autorisation déléguée et authentification

Dans le premier cas, vous utilisiez donc OAuth de la manière d’origine. Au moyen d’un jeton, vous accordez l’accès à des ressources techniques spécifiques. L’identité de l’utilisateur ne joue aucun rôle.

Dans le second scénario, vous utilisez OAuth pour partager aussi des données d’identité. Une couche d’authentification supplémentaire a été développée en complément d’OAuth à cet effet. Cette couche d’authentification est OpenID Connect (OIDC).

OAuth 2.0

Dans les exemples précédents, il est question d’OAuth 2.0. La première version d’OAuth a été développée en 2007. Elle ne prenait en charge que les sites web et reposait en grande partie sur des protocoles propriétaires, notamment ceux de Google. En 2012, OAuth 2.0 a été lancé. Cette version est beaucoup plus puissante et prend également en charge les applications et les applications mobiles. De nombreux grands acteurs technologiques ont contribué à cette version, ce qui a abouti à une refonte complète. Peu après la sortie d’OAuth 2.0, la couche OpenID Connect a été ajoutée pour l’authentification.

OAuth versus OIDC

OpenID Connect (OIDC) constitue donc une fonctionnalité complémentaire ajoutée à OAuth pour partager aussi des données d’identité. Les flux de base dédiés à l’autorisation et à l’authentification sont comparables, mais les informations transmises diffèrent. Au lieu d’un jeton d’accès contenant des autorisations, un ID token est envoyé pour les données d’identité. Et alors que les jetons d’accès sont émis par le serveur d’autorisation, l’ID token est généré par un fournisseur OIDC.

Ce sont les termes fonctionnels, l’implémentation concrète varie selon les fournisseurs. L’essentiel est qu’avec OAuth vous pouvez accorder des autorisations de manière centralisée et qu’avec OIDC vous pouvez attester l’identité d’une personne depuis un point unique. Dans un scénario SSO, l’utilisateur se connecte une seule fois au début de la session, par exemple avec un mot de passe et une authentification multifacteur. Lorsque l’utilisateur accède à une ou plusieurs applications pendant la session, son identité est confirmée immédiatement sans connexion séparée. Sous le capot, cela se fait au moyen de l’ID token.

OAuth versus SAML

OAuth est souvent comparé à SAML (Security Assertion Markup Language). Alors qu’OAuth a été conçu principalement pour les applications cloud et mobiles, SAML visait à l’origine les applications d’entreprise. SAML est également moins destiné à l’octroi d’autorisations comme OAuth. Avec SAML, il est possible de définir des droits de base, mais sa fonction principale réside dans l’authentification et le SSO.

En termes de fonctionnalité, SAML est donc surtout comparable à OIDC. Les deux solutions SSO sont utilisées en pratique dans des environnements IAM professionnels et, par exemple, le module HelloID Access Management prend en charge les deux technologies.