Technical Tutorials

Dans le paysage de la sécurité des applications modernes, peu de sujets suscitent autant de confusion ou génèrent autant de vulnérabilités critiques que la relation entre OAuth 2.0 et OpenID Connect (OIDC). Bien qu'ils soient souvent mentionnés ensemble, ils remplissent des fonctions fondamentalement différentes. OAuth 2.0 est un cadre d'autorisation, tandis qu'OpenID Connect est une couche d'authentification construite par-dessus. Comprendre cette distinction n'est pas seulement académique ; elle est essentielle pour construire des applications sécurisées, évolutives et conviviales.

L'éléphant de l'autorisation : OAuth 2.0

Au fond, OAuth 2.0 a été conçu pour résoudre un problème spécifique : comment une application tierce peut-elle accéder aux ressources d'un utilisateur sur un autre service sans manipuler les identifiants de l'utilisateur ? Pensez-y comme le fait de donner une clé de valet à votre voiture. Vous ne donnez pas votre clé maîtresse (votre nom d'utilisateur et mot de passe) ; vous donnez une clé à accès limité qui n'ouvre que la porte et démarre le moteur.

OAuth 2.0 définit quatre rôles principaux :

Propriétaire des ressources : L'utilisateur qui possède les données.
Client : L'application demandant l'accès.
Serveur d'autorisation : Le service qui authentifie l'utilisateur et émet des jetons (par exemple, Google, GitHub).
Serveur de ressources : Le service hébergeant les données protégées.

Lorsqu'un utilisateur accorde sa permission, le Serveur d'autorisation émet un Jetons d'accès (Access Token). Ce jeton est une chaîne de caractères que le Client présente au Serveur de ressources pour obtenir l'accès. Crucialement, le Jeton d'accès ne contient aucune information sur l'identité de l'utilisateur ; c'est simplement une clé pour déverrouiller des ressources.

La couche d'identité : OpenID Connect

Si OAuth 2.0 gère l'« accès », OpenID Connect gère l'« identité ». OIDC est une couche d'identité construite par-dessus le protocole OAuth 2.0. Il introduit un nouveau type de jeton : le Jetons d'identité (ID Token).

Le Jeton d'identité est un Jeton Web JSON (JWT) qui contient des revendications (claims) concernant l'événement d'authentification, telles que qui s'est connecté, quand et depuis où. Lorsque vous voyez « Se connecter avec Google » ou « Se connecter avec GitHub », vous êtes témoin d'OpenID Connect en action. Le fournisseur OIDC authentifie l'utilisateur, puis renvoie un Jeton d'identité au client, confirmant l'identité de l'utilisateur.

Différences clés en un coup d'œil

Fonctionnalité	OAuth 2.0	OpenID Connect
Objectif	Autorisation (Accès)	Authentification (Identité)
Type de jeton	Jetons d'accès	Jetons d'identité (JWT)
Cas d'utilisation	Lecture du calendrier d'un utilisateur	Vérification de l'identité de l'utilisateur

Implémentation pratique : Le flux de code d'autorisation

Pour les applications web, le flux recommandé est le Flux de code d'autorisation avec PKCE (Proof Key for Code Exchange). Ce flux garantit que même si le code d'autorisation est intercepté, il ne peut pas être utilisé par un attaquant sans le secret du client (ou le vérificateur PKCE).

Voici un exemple conceptuel de la structure de la requête :

GET /authorize?
    response_type=code&
    client_id=YOUR_CLIENT_ID&
    redirect_uri=https://yourapp.com/callback&
    scope=openid profile email&
    code_challenge=YOUR_CODE_CHALLENGE&
    code_challenge_method=S256
    HTTP/1.1

Dans cet exemple, remarquez le paramètre scope=openid. C'est le signal envoyé au serveur d'autorisation indiquant que vous demandez une authentification via OIDC, et non simplement une autorisation. Sans cette portée (scope), vous ne recevriez qu'un Jeton d'accès pour l'accès à l'API, et non un Jeton d'identité pour la vérification de l'identité.

Meilleures pratiques pour la sécurité

Implémenter correctement ces protocoles est semé d'embûches. Stockez toujours les jetons dans des cookies httpOnly lorsque cela est possible pour empêcher les attaques par Script intersite (XSS) de les voler. Ne stockez jamais les jetons dans le stockage local (local storage) sauf si absolument nécessaire, car JavaScript peut y lire. De plus, validez toujours la signature du Jeton d'identité côté serveur et vérifiez les revendications iss (émetteur) et aud (public cible) pour vous assurer que le jeton a été émis par un fournisseur de confiance pour votre application spécifique.

Conclusion

OAuth 2.0 et OpenID Connect sont des outils puissants qui, lorsqu'ils sont compris et implémentés correctement, peuvent considérablement renforcer la posture de sécurité de votre application. En séparant les responsabilités — en utilisant OAuth pour l'accès et OIDC pour l'identité — vous créez une base solide pour les applications web modernes. En tant que développeurs, notre responsabilité est d'aller au-delà du copier-coller de code et de véritablement comprendre les implications de sécurité de chaque jeton que nous émettons et validons.