Authentification par JWT ou OAuth : la mise en œuvre pas à pas

A retenir :

• JWT signé pour transmettre des droits vérifiables entre services
• OAuth pour déléguer l’accès sans partager les identifiants
• Autorisation distincte de l’authentification à chaque requête
• Vérification stricte des jetons et durée de vie limitée

JWT ou OAuth : choisir le bon mécanisme

Comprendre l’authentification et l’autorisation

Pour protéger une API, il faut d’abord distinguer deux questions : qui appelle le service, et quelles actions lui sont permises. L’authentification établit l’identité de l’appelant, tandis que l’autorisation contrôle ses droits sur chaque ressource.

Selon ITSkillsCenter, une API de catalogue peut laisser consulter les livres sans connexion, mais exiger des droits pour créer un emprunt ou supprimer un adhérent. Cette séparation évite qu’une identité valide soit confondue avec une permission générale.

Associer le protocole au type de client

JWT est un format de jeton, alors qu’OAuth 2.0 décrit un cadre de délégation d’accès. OAuth peut délivrer un jeton d’accès au format JWT, mais ses jetons ne sont pas nécessairement des JWT.

Pour une application qui agit au nom d’un utilisateur, OAuth convient à la délégation. Pour authentifier une personne auprès d’un fournisseur d’identité, OpenID Connect complète OAuth avec des éléments dédiés à l’identité.

Repères pour choisir le mécanisme :

• Utilisateur connecté à votre propre application : session ou jeton adapté
• Application tierce accédant à des ressources : OAuth avec droits limités
• Échange entre serveurs partenaires : clé d’API protégée et renouvelable
• Connexion déléguée avec identité : OAuth complété par OpenID Connect

Préparer une mise en œuvre JWT sécurisée

Émettre un jeton avec des données minimales

Dans le parcours JWT, le serveur authentifie d’abord l’utilisateur avec ses identifiants, puis construit un jeton contenant seulement les informations nécessaires. Selon ITSkillsCenter, un JWT est signé, mais cette signature numérique ne chiffre pas son contenu.

Un client peut donc lire les données encodées, même s’il ne peut pas les modifier sans invalider la signature. Évitez d’y placer un mot de passe, une clé secrète ou toute donnée personnelle qui doit rester confidentielle.

Éléments à contrôler lors de l’émission :

• Identifiant du sujet et permissions strictement nécessaires
• Émetteur et destinataire attendus par l’API
• Expiration courte adaptée à l’usage du jeton
• Algorithme de signature configuré explicitement

Vérifier chaque requête côté serveur

Le client transmet généralement le jeton d’accès dans l’en-tête d’autorisation HTTP. L’API vérifie la signature, l’émetteur, le destinataire et l’expiration avant d’appliquer les règles d’autorisation.

Pour une clé secrète partagée, tous les services capables de vérifier le jeton peuvent aussi en signer. Une signature asymétrique sépare la clé privée d’émission des clés publiques de vérification, ce qui facilite la limitation des accès.

Selon ITSkillsCenter, la protection ne s’arrête pas à l’émission : une vérification robuste est nécessaire à chaque appel. Le tableau distingue les principaux contrôles à prévoir dans une API sécurisée.

Contrôle	Question vérifiée	Risque réduit
Signature	Le jeton a-t-il été signé par une clé reconnue ?	Altération du contenu
Expiration	Le jeton est-il encore valide ?	Réutilisation prolongée
Émetteur	Le fournisseur est-il attendu ?	Jeton provenant d’une source étrangère
Destinataire	Ce jeton vise-t-il cette API ?	Réemploi sur un autre service

Configurer OAuth et le flux d’authentification

Définir les rôles et les autorisations

OAuth sépare le client, l’utilisateur, le serveur d’autorisation et l’API qui héberge les ressources. Le client demande des droits précis, puis reçoit un jeton d’accès que l’API peut contrôler sans recevoir le mot de passe de l’utilisateur.

Le choix du flux dépend du client et de son contexte. Une application mobile ou web publique ne peut pas garder un secret de manière fiable ; PKCE renforce alors l’échange d’autorisation en liant la demande initiale à l’échange du code.

Protéger les jetons et limiter les accès

Utilisez HTTPS, demandez des portées limitées et stockez les jetons selon les protections de la plateforme. Pour un navigateur, les choix de stockage doivent aussi tenir compte des attaques par script et des risques liés aux cookies.

Mesures pratiques pour la mise en œuvre :

• Enregistrer des URL de retour exactes auprès du fournisseur
• Activer PKCE pour les clients publics concernés
• Refuser les portées plus larges que le besoin réel
• Prévoir rotation, révocation ou renouvellement des jetons

Un JWT autonome est difficile à révoquer avant son expiration sans mécanisme complémentaire. Un jeton opaque vérifié auprès du serveur d’autorisation peut convenir lorsque la révocation immédiate est prioritaire.

Tester les accès et traiter les erreurs

Vérifier les scénarios autorisés et refusés

Une implémentation ne se valide pas seulement avec une connexion réussie. Testez aussi un jeton expiré, une signature invalide, un mauvais destinataire et un utilisateur authentifié dépourvu du droit demandé.

Pour l’API Catalogue, un lecteur peut consulter les notices, mais seul un bibliothécaire autorisé peut supprimer un titre. Cette règle doit être vérifiée au niveau de l’API, même si l’interface masque déjà le bouton.

Scénarios de test essentiels :

• Requête sans jeton vers une ressource protégée
• Jeton valide avec portée insuffisante
• Jeton expiré ou signé avec une clé inconnue
• Accès permis pour le rôle attendu uniquement

Choisir une stratégie adaptée aux révocations

Les sessions côté serveur permettent une révocation directe, tandis que les JWT favorisent la vérification locale par plusieurs services. OAuth répond surtout au besoin de délégation ; ces mécanismes ne sont donc pas des solutions interchangeables.

Le tableau aide à relier chaque option à son usage courant. Selon ITSkillsCenter, les clés d’API conviennent notamment aux partenaires serveur à serveur, mais elles ne remplacent pas une gestion fine des droits utilisateurs.

Mécanisme	Usage courant	Point de vigilance
Session serveur	Application contrôlée par un même service	Maintenir et protéger l’état côté serveur
JWT	Transmission de revendications vérifiables	Révocation anticipée à organiser
OAuth 2.0	Délégation d’accès à une application	Flux et portées à configurer correctement
Clé d’API	Échanges entre systèmes partenaires	Secret à protéger et renouveler

Source : ITSkillsCenter, « Concevoir une API REST — le guide de conception », ITSkillsCenter, 27 mai 2026.