OAuth
OAuth est un protocole d'autorisation ouvert qui permet à une application tierce d'obtenir un accès limité aux ressources protégées d'un utilisateur sur un autre service. Il supprime le besoin de transmettre l'identifiant et le mot de passe, protégeant ainsi les données personnelles.
Contents
Qu'est-ce que OAuth en termes simples
OAuth (Open Authorization) est un protocole d'autorisation qui permet à une application d'accéder à vos données sur un autre service sans lui transmettre votre identifiant ni votre mot de passe. À la place du mot de passe, l'application reçoit une clé d'accès temporaire spéciale (token).
En termes simples, OAuth, c'est comme un badge numérique que vous donnez à un invité pour qu'il puisse entrer chez vous, mais uniquement dans l'entrée, pas dans toutes les pièces. Vous ne lui donnez pas les clés de toutes les portes (votre mot de passe), mais seulement un badge ponctuel spécial avec des droits limités.
Un exemple classique est le bouton « Se connecter avec Google » ou « Se connecter avec VKontakte » sur n'importe quel site. Vous appuyez sur le bouton, vous êtes redirigé vers la page Google, où vous saisissez votre mot de passe (mais pas sur un site tiers !), confirmez l'accès, et le site ne reçoit que ce que vous avez autorisé — par exemple, votre nom et votre e-mail. Votre mot de passe reste secret.
OAuth résout le principal problème des anciens systèmes — auparavant, les applications demandaient votre identifiant et votre mot de passe d'un autre service, ce qui était extrêmement dangereux. Si l'application s'avérait frauduleuse, vous perdiez l'accès à tout le compte. OAuth n'accorde qu'un accès limité à des données précises pour une durée déterminée. Selon Okta, plus de 80 % des applications d'entreprise utilisent OAuth pour l'autorisation, et le nombre de tokens OAuth délivrés chaque jour se compte en milliards.
Découvrez comment OAuth est lié à la sécurité des applications web dans l'article Sécurité de l'information.
Comment fonctionne OAuth
Le processus OAuth peut être imaginé comme l'obtention d'un badge numérique. Quatre parties y participent :
- Resource Owner : c'est vous — l'utilisateur qui possède les données et donne l'autorisation.
- Client : une application tierce qui souhaite accéder à vos données (par exemple, une application mobile ou un site web).
- Serveur d'autorisation : le serveur qui vérifie votre identité et délivre les tokens (par exemple, les comptes Google, GitHub).
- Serveur de ressources : le serveur où vos données sont stockées (par exemple, Google Drive ou l'API du profil VK).
Le processus se déroule ainsi :
- Vous appuyez sur « Se connecter avec Google » sur un site tiers.
- Le site vous redirige vers le serveur Google, où vous saisissez votre mot de passe.
- Google demande : « Autorisez-vous ce site à accéder à votre nom et à votre e-mail ? »
- Vous appuyez sur « Autoriser ».
- Google délivre un code temporaire au site et vous redirige en arrière.
- Le site échange le code contre un token d'accès.
- Le site utilise le token pour demander vos données via l'API Google.
Découvrez comment fonctionnent les tokens dans l'article Token de sécurité.
Types de grants OAuth 2.0
OAuth 2.0 prend en charge plusieurs flux d'autorisation (grants), choisis en fonction du type d'application (web, mobile, serveur) et du niveau de confiance :
- Authorization Code Grant : le flux le plus répandu et le plus sécurisé pour les applications web et mobiles. Le client reçoit un code d'autorisation, qu'il échange ensuite contre un token d'accès. Le code est transmis via le navigateur de l'utilisateur, et le token — via un canal sécurisé entre le serveur client et le serveur d'autorisation.
- Implicit Grant (obsolète) : un flux simplifié pour les applications monopages (SPA), où le token est renvoyé directement au navigateur. Considéré comme moins sécurisé, il est déconseillé dans la pratique moderne.
- Resource Owner Password Credentials Grant : un flux où l'utilisateur transmet son identifiant et son mot de passe directement au client. Utilisé uniquement pour les applications de confiance (par exemple, les applications mobiles officielles des banques). Une méthode à haut risque.
- Client Credentials Grant : utilisé pour les interactions de serveur à serveur où aucun utilisateur n'intervient. Le client s'authentifie avec ses propres identifiants (client ID et client secret) et obtient un token pour accéder aux ressources protégées.
Le choix du bon grant est une étape déterminante dans la conception de la sécurité d'une application. Un mauvais choix peut entraîner des vulnérabilités et une compromission des données.
OAuth 1.0 vs OAuth 2.0
OAuth 2.0 est la version moderne du protocole qui a remplacé OAuth 1.0. Principales différences :
- Simplicité : OAuth 2.0 est nettement plus simple pour les développeurs. La cryptographie complexe de signature des requêtes n'est pas nécessaire (dans OAuth 1.0, il fallait générer une signature numérique pour chaque requête).
- Flexibilité : OAuth 2.0 prend en charge différents cas d'utilisation : applications web, applications mobiles, appareils sans navigateur (IoT), interactions de serveur à serveur.
- Tokens : OAuth 2.0 utilise des tokens d'accès et des refresh tokens, ce qui permet de prolonger l'accès sans ressaisie des identifiants de l'utilisateur.
- Sécurité : OAuth 2.0 repose sur la transmission HTTPS pour protéger les tokens et s'appuie davantage sur TLS pour la sécurité.
Aujourd'hui, OAuth 2.0 est la norme de facto pour l'autorisation sur Internet. Il est utilisé par Google, Facebook, GitHub, Microsoft, Yandex et des milliers d'autres services. Découvrez comment OAuth s'intègre aux API dans l'article Infrastructure.
Sécurité d'OAuth
Bien qu'OAuth soit un protocole sécurisé, il existe des risques qu'il est important de prendre en compte lors de son utilisation :
- Interception de token : si un attaquant intercepte un token d'accès (par exemple, via une connexion non sécurisée ou une attaque Man-in-the-Middle), il peut l'utiliser avant son expiration. L'utilisation de HTTPS est obligatoire.
- Hameçonnage (phishing) : des attaquants peuvent créer de fausses pages de connexion imitant le serveur d'autorisation pour voler des identifiants. Il est important de toujours vérifier l'URL avant de saisir un mot de passe.
- Attaques CSRF (Cross-Site Request Forgery) : des attaques où un attaquant amène l'utilisateur à effectuer des actions non souhaitées sur un site où il est authentifié. Pour s'en protéger, le paramètre state est utilisé dans les requêtes OAuth.
- Compromission du client secret : si un attaquant obtient le client secret (la clé secrète de l'application), il peut se faire passer pour une application légitime. Conservez le client secret en lieu sûr.
Pour renforcer la sécurité, il est recommandé d'utiliser une durée de vie courte pour les tokens d'accès (par exemple, 1 heure) et des refresh tokens pour prolonger la session sans ressaisie du mot de passe. Il est également important d'utiliser PKCE (Proof Key for Code Exchange) pour se protéger contre l'interception du code d'autorisation dans les applications mobiles.
Frequently asked questions
Qu'est-ce que OAuth, en termes simples ?
OAuth est un moyen de se connecter à un site sans créer de nouvel identifiant ni mot de passe. Vous appuyez sur « Se connecter avec Google » ou « Se connecter avec VKontakte », donnez votre accord, et le site n'obtient accès qu'à ce que vous avez autorisé (par exemple votre nom et votre e-mail). Votre mot de passe n'est jamais transmis au site. C'est comme un badge numérique à droits limités au lieu de remettre les clés de tout l'appartement. Lisez la sécurité des données dans l'article Sécurité de l'information.
Comment fonctionne OAuth 2.0 ?
OAuth 2.0 fonctionne sur le principe du « badge numérique » : vous donnez votre accord à un service (par exemple Google), et il délivre à l'application une clé temporaire (token) pour accéder à vos données. L'application ne connaît pas votre mot de passe et ne peut pas accéder à ce que vous n'avez pas autorisé. Quatre parties interviennent dans le processus : le propriétaire de la ressource (vous), le client (l'application), le serveur d'autorisation (Google) et le serveur de ressources (API). Le token est valable un temps limité et peut être révoqué à tout moment. Lisez le fonctionnement des tokens dans l'article Token de sécurité.
Quelle est la différence entre OAuth 1.0 et OAuth 2.0 ?
OAuth 2.0 est la version moderne du protocole. Il est plus simple d'utilisation pour les développeurs (pas de signature complexe des requêtes), prend en charge davantage de scénarios (applications mobiles, objets connectés, serveur à serveur) et utilise des refresh tokens pour prolonger l'accès sans nouvelle saisie. OAuth 2.0 s'appuie davantage sur HTTPS pour la sécurité. Aujourd'hui, OAuth 2.0 est utilisé partout, tandis qu'OAuth 1.0 est considéré comme obsolète.
Pourquoi utiliser OAuth plutôt que de transmettre simplement un mot de passe ?
OAuth est plus sûr que la transmission d'un mot de passe. Si l'application s'avère frauduleuse, avec OAuth vous ne lui donnez accès qu'à des données limitées (par exemple uniquement votre nom), et non à tout le compte. Vous pouvez révoquer l'accès à tout moment dans les paramètres de votre compte. En transmettant un mot de passe, vous risquez tout le compte — un attaquant peut accéder à toutes vos données, y compris e-mail, documents et informations de paiement. Lisez la protection des comptes dans l'article Vérification.
OAuth est-il sûr et quels sont les risques ?
OAuth est considéré comme sûr lorsqu'il est correctement utilisé. Les tokens sont transmis via un canal sécurisé (HTTPS), ont une durée de validité limitée et un périmètre de droits restreint. Il existe cependant des risques : interception de token (attaque MITM), hameçonnage (fausse page de connexion), attaques CSRF et compromission du secret client. Pour vous protéger, utilisez HTTPS, des durées de vie courtes des tokens, le paramètre state contre le CSRF et PKCE pour les applications mobiles.
Où utilise-t-on OAuth et quelles entreprises l'utilisent ?
OAuth est utilisé dans presque toutes les applications web et mobiles modernes. Les boutons « Se connecter avec Google », « Se connecter avec Facebook », « Se connecter avec Yandex », « Se connecter avec VKontakte » sont OAuth. OAuth est également utilisé dans les API pour l'échange de données entre services (par exemple l'intégration d'un CRM avec des services de messagerie), dans les systèmes d'entreprise pour l'authentification unique (SSO) et dans les objets connectés. Il est utilisé par Google, Facebook, GitHub, Microsoft, Yandex, VKontakte et des milliers d'autres services. Lisez la configuration des API dans l'article Infrastructure.
Quelle est la différence entre OAuth et le SSO (authentification unique) ?
OAuth est un protocole d'autorisation (ce qu'il est permis de faire avec vos données), tandis que le SSO (Single Sign-On) est une solution d'authentification (qui vous êtes). Le SSO permet de se connecter une seule fois à un système et d'obtenir l'accès à toutes les applications sans ressaisir de mot de passe. OAuth peut faire partie d'une solution SSO, mais ce sont des notions différentes. Le SSO repose souvent sur les protocoles SAML ou OpenID Connect (qui utilise OAuth 2.0 pour l'authentification). OAuth donne accès aux données, le SSO simplifie la connexion à plusieurs systèmes.
Other terms in «Information Security»
Was this information helpful?
Protect your network today
Leave a request — our information security specialists will help you select, configure and integrate oauth into your infrastructure. We will protect your data from threats.