Authentification par JWT ou OAuth : le principe et ce que ça résout
Authentification par JWT ou OAuth 2.0 : deux rôles différents
Lorsqu’une personne se connecte à une application, le système doit vérifier son identité, puis déterminer ce qu’elle peut consulter ou modifier. Cette étape d’Authentification s’accompagne donc d’une question distincte : comment transmettre et contrôler les droits d’accès au fil des requêtes ?
JWT et OAuth 2.0 répondent à des besoins liés, mais ne sont pas deux méthodes interchangeables. Un JWT est un format de jeton signé ; OAuth 2.0 est un cadre de Délégation d’accès qui permet à une application d’obtenir des permissions auprès d’un service, sans recevoir le mot de passe de l’utilisateur.
JWT : un jeton qui transporte des informations vérifiables
Imaginons une entreprise fictive, Atelier Nord, qui propose une application de gestion de commandes. Après la connexion, son serveur peut délivrer un JWT contenant un identifiant, des permissions et une date d’expiration ; l’application le renvoie ensuite pour accéder à certaines fonctions.
Le serveur vérifie la Signature numérique du jeton pour détecter une modification. Cette vérification ne signifie pas que toutes les données sont secrètes : un JWT signé est généralement lisible par son détenteur, et ne doit donc pas contenir de mot de passe ou d’information confidentielle.
La Expiration du jeton limite la période pendant laquelle celui-ci peut être utilisé. Une durée courte réduit les conséquences d’un vol, mais suppose de prévoir un renouvellement sécurisé ou une nouvelle connexion lorsque le jeton n’est plus valide.
Repères essentiels sur le JWT :
- Format de jeton, et non protocole complet de connexion
- Signature contrôlable sans consulter systématiquement une base
- Données généralement lisibles, même lorsqu’elles sont signées
- Révocation anticipée difficile sans mécanisme serveur complémentaire
OAuth 2.0 : déléguer une autorisation sans partager le mot de passe
Une fois distingué le format du jeton, le rôle d’OAuth 2.0 devient plus clair : le protocole encadre l’Autorisation, c’est-à-dire l’accès limité à une ressource. Par exemple, un service de calendrier peut permettre à une application d’afficher des événements, sans lui communiquer le mot de passe du compte.
Le parcours d’autorisation et le jeton d’accès
L’utilisateur est dirigé vers le fournisseur de service, où il se connecte et approuve des permissions précises. L’application reçoit ensuite un code d’autorisation qu’elle échange, selon le flux approprié, contre un Jeton d’accès permettant d’appeler certaines API.
Pour les applications web monopages et mobiles, le flux Authorization Code avec PKCE est une pratique courante. PKCE protège l’échange du code en liant la demande initiale à une valeur conservée par le client ; le paramètre « state » aide également à contrer des requêtes forgées.
OAuth 2.0 ne définit pas, à lui seul, un protocole complet d’Identité numérique. Lorsqu’une application doit obtenir des informations normalisées sur la personne connectée, OpenID Connect ajoute cette couche d’identité au-dessus d’OAuth 2.0.
Dans le parcours OAuth, les éléments à distinguer sont :
- Fournisseur : service qui contrôle les ressources
- Application cliente : outil demandant un accès circonscrit
- Permissions : actions autorisées par le consentement
- Jeton d’accès : justificatif transmis aux API concernées
JWT ou session serveur : choisir selon le contrôle nécessaire
Le choix du jeton prend tout son sens lorsqu’on le compare aux sessions classiques. Dans une session serveur, le navigateur conserve un identifiant, souvent dans un cookie, tandis que l’état de connexion reste stocké côté serveur.
Comparer révocation, stockage et architecture
Une session peut être supprimée immédiatement dans la base de données, ce qui facilite la déconnexion forcée après la perte d’un appareil. Un JWT autonome est plus simple à vérifier dans plusieurs services, mais il reste en principe utilisable jusqu’à son expiration, sauf contrôle complémentaire.
Selon les besoins de l’application, aucun choix n’est universel : une API distribuée peut tirer parti de jetons vérifiables localement, tandis qu’un espace d’administration sensible peut privilégier des sessions révocables. Atelier Nord pourrait aussi conserver une session côté serveur et utiliser des jetons courts pour des appels API spécifiques.
| Critère | Session serveur | JWT |
|---|---|---|
| État de connexion | Conservé côté serveur | Informations portées par le jeton |
| Révocation immédiate | Simple par suppression de session | Nécessite un dispositif complémentaire |
| Vérification des requêtes | Consultation du stockage de sessions | Validation de la signature et des claims |
| Usage fréquent | Applications web avec contrôle centralisé | API distribuées ou échanges entre services |
Critères de choix pour l’architecture :
- Besoin de couper rapidement une session compromise
- Nombre de services qui doivent vérifier les accès
- Capacité à protéger cookies, clés et jetons renouvelables
- Exigences de journalisation et de contrôle des permissions
Sécurisation des API : protéger les jetons et les échanges
Une fois l’architecture choisie, la Sécurisation des API dépend surtout de la façon dont les identifiants sont émis, stockés et contrôlés. Un jeton correctement signé ne compense pas un transport non chiffré, une durée excessive ou des permissions trop larges.
Réduire les risques liés au stockage et à la durée
Sur une application web, un cookie configuré avec HttpOnly, Secure et un attribut SameSite adapté réduit certaines expositions, notamment l’accès direct au cookie par du code exécuté dans le navigateur. Le stockage dans localStorage présente d’autres risques en cas de faille de script intersite ; le choix doit tenir compte de l’architecture et des défenses mises en place.
Les serveurs doivent vérifier la signature, l’émetteur, l’audience et l’expiration avant d’accepter un JWT. Ils doivent aussi appliquer les permissions côté serveur : masquer un bouton dans l’interface ne protège pas une route accessible directement.
Mesures pratiques pour limiter les conséquences d’un incident :
- Utiliser HTTPS pour les échanges entre client et serveur
- Limiter la durée des jetons d’accès selon leur usage
- Protéger les clés de signature et organiser leur rotation
- Valider les permissions à chaque opération sensible
Selon les recommandations courantes de conception sécurisée, réduire les privilèges accordés et protéger les secrets sont des mesures complémentaires. Un jeton exposé ne doit pas donner automatiquement accès à toutes les fonctions du compte.
Mettre en œuvre OAuth et JWT sans confondre leurs fonctions
La dernière étape consiste à assembler les mécanismes sans leur attribuer le même rôle. OAuth 2.0 organise l’autorisation déléguée ; OpenID Connect fournit des éléments d’identité ; JWT peut servir de format à certains jetons échangés ou délivrés par le système.
Une intégration adaptée au projet
Pour une connexion avec un fournisseur externe, l’équipe configure un client OAuth, limite les permissions demandées et protège le flux de redirection. Si l’application doit reconnaître l’utilisateur, elle s’appuie sur OpenID Connect et vérifie les informations d’identité selon les règles du fournisseur.
Pour des API internes, un JWT peut transporter des claims nécessaires à la décision d’accès, à condition que les services vérifient correctement leur origine et leur validité. Selon les exigences de révocation, l’équipe peut associer des jetons courts à un mécanisme serveur de renouvellement ou choisir des sessions.
Le recours à une bibliothèque ou à un fournisseur d’identité peut éviter de réécrire les flux sensibles, mais ne supprime pas la responsabilité de configurer les redirections, les secrets et les permissions. Avant le déploiement, il faut tester les erreurs d’expiration, la déconnexion, la révocation et les tentatives d’accès non autorisées.
| Besoin | Mécanisme adapté | Point de contrôle |
|---|---|---|
| Connexion via un fournisseur externe | OAuth 2.0 avec flux sécurisé | Redirections, state et PKCE |
| Informations standardisées sur l’utilisateur | OpenID Connect | Validation de l’ID Token |
| Vérification distribuée d’accès API | JWT signé à durée limitée | Signature, audience et permissions |
| Déconnexion immédiate et contrôle central | Session serveur | Suppression ou invalidation de session |
Selon la documentation des protocoles OAuth 2.0 et OpenID Connect, séparer autorisation et identité aide à concevoir des flux plus explicites. La décision utile n’est donc pas « JWT ou OAuth », mais quel mécanisme répond à chaque besoin.
