OAuth 2 : définition et fonctionnement (Google, LinkedIn)

OAuth 2, c'est quoi ? La définition simple

<strong>OAuth 2 est un protocole d'autorisation qui permet à une application tierce d'accéder à une ressource protégée au nom d'un utilisateur, sans jamais manipuler son mot de passe.</strong> Le principe tient en une image : plutôt que de confier la clé de votre maison, vous remettez un badge qui n'ouvre que le garage, et seulement pendant une heure. Ce badge s'appelle un access token.

La version 2.0 est décrite dans la RFC 6749, publiée par l'IETF en 2012. Elle a remplacé OAuth 1.0, jugé trop complexe à implémenter à cause de ses signatures cryptographiques sur chaque requête. Aujourd'hui, Google, LinkedIn, Microsoft, GitHub ou Facebook reposent tous sur ce standard pour ouvrir leurs données à d'autres apps.

Autorisation et authentification : la confusion classique

OAuth 2 répond à la question « que peut faire cette application ? ». Il ne répond pas à « qui est l'utilisateur ? ». Cette nuance fait partie de ce que les équipes techniques oublient le plus souvent. Pour l'authentification et l'identity de la personne, on ajoute OpenID Connect, qui fournit un second jeton, l'ID token, contenant l'identité vérifiée de l'utilisateur.

Quand vous cliquez sur « Sign in with Google », vous utilisez donc les deux : OAuth 2 pour l'autorisation, OpenID Connect pour savoir qui vient de se connecter. Dans le langage courant, on dit simplement « connexion OAuth », mais un développeur sérieux fait la différence.

OAuth 2.0 et OAuth 2.1 : quelle différence ?

OAuth 2.1 est une consolidation en cours de finalisation à l'IETF. Elle ne change pas la logique du protocole, elle retire ce qui s'est révélé dangereux. Le flux implicite et le flux par mot de passe disparaissent, et la protection PKCE devient obligatoire pour l'authorization code flow. Si vous lancez un projet aujourd'hui, suivre les règles de la 2.1 est le bon réflexe.

À quoi sert OAuth 2 pour une entreprise ?

Pour un dirigeant de PME, OAuth 2 n'est pas un sujet d'ingénieur isolé. Il touche directement la conversion, la sécurité et la confiance de vos clients. Voici ce qu'il rend possible au quotidien.

• <strong>La connexion en un clic</strong> : un bouton Google ou LinkedIn évite la création d'un énième compte et réduit l'abandon à l'inscription.
• <strong>La connexion entre vos outils</strong> : votre CRM lit votre agenda Google, votre logiciel de facturation récupère vos ventes, sans que personne ne partage de mot de passe.
• <strong>La sécurité des accès</strong> : chaque application reçoit un droit précis et révocable, au lieu d'un accès total et permanent.
• <strong>La gestion des droits</strong> : vous retirez l'accès d'un outil depuis votre compte Google sans changer vos credentials partout.
• <strong>Les connexions machine à machine</strong> : deux serveurs échangent des données via une API sans intervention humaine.

C'est aussi un argument de sécurité. Moins votre site stocke de mots de passe, moins il offre de prise aux attaques par force brute et aux fuites de bases de données. Déléguer la connexion à Google revient à profiter de sa propre infrastructure de protection, double authentification comprise.

Comment fonctionne OAuth 2 : les rôles et le flow

Le fonctionnement d'OAuth repose sur quatre rôles bien séparés. Les comprendre suffit à saisir l'essentiel du protocole, quel que soit le fournisseur.

Les quatre acteurs du protocole

• <strong>Le propriétaire de la ressource</strong> : vous, l'utilisateur qui possède les données et donne son accord.
• <strong>Le client</strong> : l'application qui demande l'accès, par exemple votre site ou votre logiciel métier.
• <strong>L'authorization server</strong> : le serveur qui vérifie votre identité, affiche l'écran de consentement et délivre les jetons. Chez Google, c'est accounts.google.com.
• <strong>Le resource server</strong> : le serveur qui détient les données protégées, comme l'API Gmail ou l'API LinkedIn, et qui contrôle chaque jeton reçu.

L'access token et le refresh token

Un access token est une chaîne de caractères que le client joint à chaque requête vers l'API. Ce token is une sorte de laissez-passer à durée courte, souvent de l'ordre d'une heure selon les fournisseurs, et limité à des permissions appelées scopes. Celui qui détient le jeton peut l'utiliser : c'est pourquoi on parle de jeton « porteur », ou bearer token.

Pour éviter de redemander l'accord à l'utilisateur toutes les heures, le serveur peut fournir un refresh token. Il sert uniquement à obtenir un new access token auprès de l'authorization server. Il doit donc être stocké côté serveur, chiffré, et jamais dans le navigateur.

L'authorization code flow, étape par étape

L'authorization code flow est le parcours recommandé pour les sites web et les applications mobiles. Il se déroule en cinq temps.

• Le client redirige le browser de l'utilisateur vers the authorization server, avec la liste des scopes demandés et une adresse de retour.
• L'utilisateur se connecte chez Google ou LinkedIn et accepte, ou refuse, le partage demandé.
• Le serveur renvoie le navigateur vers le site avec un code d'autorisation à usage unique et de courte durée.
• Le serveur du client échange ce code contre an access token, en s'identifiant avec son secret, loin des regards.
• Le client appelle l'API avec le jeton, et le resource server renvoie les données autorisées.

L'intérêt de ce détour est simple : le jeton ne transite jamais dans l'URL ni dans le navigateur. Pour les applications browser-based et mobiles, qui ne peuvent pas garder un secret, on ajoute PKCE, décrit dans la RFC 7636. Le client crée une clé aléatoire au départ et prouve qu'il la possède au moment de l'échange, ce qui rend un code volé inutilisable.

Les grant types d'OAuth 2.0 : lequel choisir ?

Les grant types désignent les différentes façons d'obtenir un jeton. Chacun correspond à un contexte précis, et choisir le mauvais est une faille en soi.

Authorization code avec PKCE

C'est le choix par défaut dès qu'un humain intervient : site web, application mobile, application monopage. Il couvre la quasi-totalité des connexions Google ou LinkedIn que vous verrez sur un site.

Client credentials

Le client credentials flow sert aux échanges entre serveurs, sans utilisateur. Votre logiciel s'identifie avec son propre identifiant et son secret pour appeler une API, par exemple pour synchroniser chaque nuit un catalogue produit.

Device code

Le device flow concerne les appareils sans clavier pratique : télévision connectée, borne, outil en ligne de commande. L'écran affiche un code court, et l'utilisateur valide depuis son téléphone.

Les flux à abandonner

Le flux implicite renvoyait le jeton directement dans l'URL, ce qui l'exposait à l'historique et aux scripts malveillants. Le flux par mot de passe obligeait l'utilisateur à confier ses identifiants à l'application, ce qui contredit l'idée même d'OAuth. Les deux sont retirés d'OAuth 2.1 : si un prestataire vous les propose, demandez pourquoi.

Exemple concret : la connexion Google et LinkedIn

Côté Google, la logique est identique. On déclare le projet dans la console Google Cloud, on configure l'écran de consentement et les adresses de retour autorisées, puis on choisit des scopes aussi étroits que possible. Google met aussi à disposition l'OAuth 2.0 Playground, un outil en ligne pour tester les échanges de jetons avant d'écrire la moindre ligne de code.

Quand nous intégrons ce type de connexion dans un projet de création de logiciel, l'essentiel du travail ne porte pas sur le bouton. Il porte sur la gestion des jetons, des comptes déjà existants et des cas où l'utilisateur refuse le partage.

Les erreurs courantes avec OAuth 2

OAuth 2 est robuste quand il est bien appliqué. La plupart des incidents viennent de raccourcis pris pendant le développement, qui finissent en production.

• <strong>Confondre autorisation et identité</strong> : utiliser un access token comme preuve de connexion, au lieu de valider l'ID token d'OpenID Connect.
• <strong>Stocker les jetons dans le navigateur</strong> : un jeton en localStorage peut être volé par une faille XSS.
• <strong>Oublier le paramètre state</strong> : sans lui, un attaquant peut injecter sa propre session dans le parcours de connexion.
• <strong>Accepter n'importe quelle adresse de retour</strong> : les redirections doivent être déclarées à l'identique, sans joker.
• <strong>Demander trop de scopes</strong> : un écran de consentement trop gourmand fait fuir les utilisateurs et alourdit la validation chez Google.
• <strong>Négliger le HTTPS</strong> : tout l'échange repose sur un canal chiffré, donc sur un certificat SSL valide.

Questions fréquentes