OAuth 2.0

Vous utilisez une application de gestion de projet qui veut accéder à votre Google Calendar. Sans OAuth, cette application devrait vous demander votre mot de passe Google. Vous donneriez un accès total à votre compte à un tiers, sans aucun contrôle sur ce qu'il en fait. OAuth 2.0 résout ce problème : permettre à une application d'accéder à vos données sans jamais connaître votre mot de passe.

Le problème : le partage de mots de passe

Avant OAuth, le seul moyen pour une application tierce d'accéder à vos données était de vous demander vos identifiants. Vous donniez votre email et mot de passe Google à une app de calendrier, votre login Twitter à un client tiers, vos credentials bancaires à un agrégateur.

Les problèmes sont évidents :

L'application tierce a un accès total — pas moyen de limiter à "lecture seule du calendrier"
Vous ne pouvez pas révoquer l'accès sans changer votre mot de passe
Si l'application est compromise, votre mot de passe est exposé
Aucune traçabilité sur ce que l'application fait avec vos données

Les 4 acteurs d'OAuth 2.0

OAuth 2.0 introduit une séparation claire des rôles :

Resource Owner — vous, l'utilisateur qui possède les données
Client — l'application tierce qui veut accéder à vos données
Authorization Server — le serveur qui vérifie votre identité et délivre les tokens (ex: accounts.google.com)
Resource Server — le serveur qui héberge vos données protégées (ex: calendar.google.com)

L'Authorization Code Flow

C'est le flow le plus courant et le plus sécurisé. Voici comment il fonctionne quand vous cliquez "Se connecter avec Google" :

1. L'utilisateur clique "Se connecter avec Google"
   → Le Client redirige vers Google (Authorization Server)

2. Google affiche l'écran de consentement
   "L'app X souhaite accéder à votre calendrier"
   → L'utilisateur accepte

3. Google redirige vers le Client avec un code temporaire
   → https://monapp.com/callback?code=abc123&state=xyz

4. Le Client échange le code contre des tokens (côté serveur)
   → POST https://oauth2.googleapis.com/token
     { code: "abc123", client_secret: "..." }

5. Google répond avec un Access Token (et un Refresh Token)
   → { access_token: "ya29...", refresh_token: "1//0e..." }

6. Le Client utilise l'Access Token pour accéder aux données
   → GET https://www.googleapis.com/calendar/v3/events
     Authorization: Bearer ya29...

Le point clé : le mot de passe n'est jamais partagé avec l'application tierce. L'utilisateur s'authentifie directement auprès de Google, et l'application ne reçoit qu'un token avec des permissions limitées.

Les Scopes : limiter les permissions

Les scopes définissent précisément ce que l'application peut faire. L'utilisateur voit ces permissions sur l'écran de consentement et peut les accepter ou les refuser.

Scope	Permission
`calendar.readonly`	Lire les événements du calendrier
`calendar.events`	Lire et modifier les événements
`profile`	Accéder au nom et à la photo de profil
`email`	Accéder à l'adresse email

Une application qui demande calendar.readonly ne pourra jamais créer ou supprimer des événements, même si son token est volé. C'est le principe du moindre privilège appliqué à la délégation d'accès.

Autres Grant Types

L'Authorization Code Flow n'est pas le seul. OAuth 2.0 définit plusieurs flows adaptés à différents contextes :

Client Credentials — pour la communication machine-to-machine, sans utilisateur. Un microservice qui appelle une API interne. Le client s'authentifie directement avec son client_id et client_secret.

POST /oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=my-service
&client_secret=secret123
&scope=api.read

Device Code — pour les appareils sans navigateur (TV, CLI, IoT). L'appareil affiche un code, l'utilisateur le saisit sur un autre appareil avec un navigateur pour autoriser l'accès.

OAuth 2.0 vs OpenID Connect

Une confusion fréquente : OAuth 2.0 gère l'autorisation (accéder à des ressources), pas l'authentification (prouver qui vous êtes).

OpenID Connect (OIDC) est une couche au-dessus d'OAuth 2.0 qui ajoute l'authentification. Quand vous cliquez "Se connecter avec Google", c'est OIDC qui est utilisé — pas OAuth seul.

	OAuth 2.0	OpenID Connect
Objectif	Autorisation — accéder à des ressources	Authentification — prouver l'identité
Token principal	Access Token	ID Token (JWT)
Question	"Que peut faire cette app ?"	"Qui est cet utilisateur ?"
Cas d'usage	Accéder au calendrier Google	"Se connecter avec Google"

En pratique, la plupart des implémentations "Login with Google/GitHub/Facebook" utilisent OIDC (qui s'appuie sur OAuth 2.0).

Les erreurs de sécurité courantes

Ne pas valider le paramètre state. Le state est un token anti-CSRF généré par le client avant la redirection. Si vous ne le vérifiez pas au retour, un attaquant peut injecter son propre code d'autorisation.

Exposer le client_secret côté client. Le secret doit rester côté serveur. Dans une SPA (Single Page Application), utilisez le PKCE (Proof Key for Code Exchange) qui remplace le secret par un challenge cryptographique.

Ne pas valider le redirect_uri. Si l'Authorization Server accepte n'importe quelle URL de redirection, un attaquant peut rediriger le code d'autorisation vers son propre serveur.

Utiliser l'Implicit Flow. Ce flow (qui retourne directement un token dans l'URL) est déprécié depuis OAuth 2.1. Utilisez Authorization Code + PKCE à la place, même pour les SPA.

Demander des scopes trop larges. Demander un accès total quand vous n'avez besoin que de la lecture du profil brise la confiance de l'utilisateur et augmente les risques en cas de compromission.

OAuth 2.0 est le standard qui a rendu possible l'écosystème d'applications interconnectées que nous utilisons au quotidien. Il repose sur un principe simple : ne jamais partager de mot de passe, déléguer l'accès avec des permissions granulaires, et permettre la révocation à tout moment. Combinez-le avec OpenID Connect pour l'authentification, et avec PKCE pour les applications frontend — vous avez une base solide pour sécuriser vos intégrations.