Authentification oauth développement web : notre décryptage
Une application qui souhaite accéder aux dépôts GitHub d’un utilisateur n’a pas besoin de connaître son mot de passe. OAuth lui permet de demander une autorisation limitée, puis d’utiliser un jeton d’accès pour appeler une API.
Cette distinction est essentielle en développement web : OAuth organise l’accès aux ressources, tandis qu’OpenID Connect sert à établir une identité. Comprendre les flux OAuth aide à bâtir une connexion sécurisée et une meilleure protection des données.
À retenir : les bases de l’authentification OAuth
- Autorisation distincte de l’authentification
- Permissions limitées selon les ressources demandées
- Flux adaptés au type d’application
- Secrets conservés dans un environnement serveur protégé
- Librairies éprouvées pour les déploiements en production
OAuth en développement web : autorisation et identité
Pourquoi OAuth ne suffit pas pour authentifier un utilisateur
Pour comprendre les flux OAuth, il faut d’abord distinguer l’autorisation de l’authentification, deux notions souvent confondues dans les interfaces de connexion. OAuth 2.0 répond à une question précise : une application peut-elle accéder à certaines ressources au nom d’un utilisateur ?
Selon le cadre défini par la RFC 6749 de l’IETF, le protocole délègue des droits sans transmettre le mot de passe du compte concerné. Par exemple, un outil de gestion de projets peut demander l’accès en lecture à des dépôts GitHub, sans obtenir les identifiants GitHub.
Le rôle d’OpenID Connect dans une connexion sécurisée
Lorsqu’un site propose « Se connecter avec Google », OpenID Connect, souvent abrégé OIDC, complète OAuth avec une couche d’identité. Il fournit notamment des informations permettant à l’application de vérifier qui s’est connecté.
Selon la spécification OpenID Connect Core de l’OpenID Foundation, OIDC s’appuie sur OAuth 2.0 plutôt que de le remplacer. Cette différence évite une erreur de conception fréquente : traiter un jeton destiné à autoriser l’accès à une API comme une preuve suffisante d’identité.
Les éléments à distinguer dans une intégration :
- OAuth 2.0 pour déléguer l’accès à des ressources
- OpenID Connect pour vérifier une identité utilisateur
- Jeton d’accès pour appeler une API autorisée
- Portée demandée pour limiter les permissions accordées
| Besoin | Mécanisme | Exemple d’usage |
|---|---|---|
| Déléguer un accès | OAuth 2.0 | Lire des dépôts GitHub |
| Vérifier une identité | OpenID Connect | Connexion avec un fournisseur d’identité |
| Appeler un service | Jeton d’accès | Requête vers une API autorisée |
| Limiter les droits | Portées de permission | Accès en lecture plutôt qu’en écriture |
Flux OAuth : choisir le bon échange de jetons
Authorization Code pour une application avec serveur
Une fois le besoin clarifié, le choix du flux dépend surtout de l’endroit où l’application peut protéger ses secrets. Pour un site disposant d’un backend, le flux Authorization Code est généralement adapté : le navigateur reçoit un code, puis le serveur l’échange contre un jeton.
Le secret du client reste alors côté serveur et ne figure pas dans le code livré au navigateur. Dans une boutique fictive, par exemple, le backend peut demander l’accès à un calendrier externe sans exposer ses identifiants techniques aux visiteurs.
PKCE pour les applications mobiles et les interfaces web
À l’inverse, une application mobile ou une interface monopage ne peut pas garder un secret statique confidentiel. La RFC 7636 de l’IETF recommande PKCE, qui lie l’échange du code à un vérificateur temporaire créé pour la requête.
Selon cette spécification, le client envoie d’abord une empreinte du vérificateur, puis présente celui-ci lors de l’échange final. Un code intercepté pendant le retour vers l’application ne suffit donc pas, à lui seul, pour obtenir le jeton correspondant.
Les choix de flux selon l’architecture :
- Authorization Code pour une application avec backend sécurisé
- Authorization Code avec PKCE pour mobile et navigateur
- Client Credentials pour les échanges entre serveurs
- Secret client conservé côté serveur lorsqu’il existe
| Flux | Utilisateur présent | Contexte adapté |
|---|---|---|
| Authorization Code | Oui | Application web avec backend |
| Authorization Code avec PKCE | Oui | Application mobile ou monopage |
| Client Credentials | Non | Communication entre services |
| Identifiants du client | Selon le flux | Stockage serveur pour les secrets privés |
Sécurité web OAuth : protéger jetons et données
Réduire les risques liés aux jetons et aux secrets
Le flux choisi ne garantit pas, à lui seul, une sécurité web satisfaisante : le stockage et la durée de vie des jetons comptent aussi. Un jeton d’accès sert aux appels autorisés et devrait rester hors des journaux, des URL et du stockage accessible inutilement au navigateur.
Un jeton de renouvellement peut obtenir de nouveaux jetons sans solliciter à nouveau l’utilisateur, mais il demande une protection renforcée. Il faut aussi restreindre les permissions, valider les adresses de retour et éviter de conserver un secret client dans le code public.
Préférer une bibliothèque éprouvée en production
Pour une démonstration pédagogique, implémenter OAuth à la main peut éclairer les redirections et les échanges HTTP. En production, les cas limites, la validation des paramètres et la gestion des erreurs rendent généralement préférable une bibliothèque maintenue et adaptée au framework utilisé.
Une équipe utilisant Next.js peut examiner une solution conçue pour cet écosystème, tandis qu’un autre projet choisira une bibliothèque compatible avec son architecture. Le bon niveau de protection dépend du risque réel : un outil interne à un seul administrateur n’a pas forcément les mêmes besoins qu’un service public manipulant des données sensibles.
Contrôles utiles avant la mise en production :
- Réduction des permissions au strict besoin fonctionnel
- Protection serveur des secrets et jetons de renouvellement
- Validation stricte des URI de redirection autorisées
- Journalisation excluant les identifiants et jetons sensibles
- Bibliothèque maintenue et configuration régulièrement révisée
Source : IETF, « The OAuth 2.0 Authorization Framework », RFC 6749, 2012 ; IETF, « Proof Key for Code Exchange by OAuth Public Clients », RFC 7636, 2015 ; OpenID Foundation, « OpenID Connect Core 1.0 ».
