Vous avez mis en place une application web sur mesure ou un logiciel SaaS, et maintenant vous exposez vos données via une API. Mais comment protéger cette API sans ralentir vos utilisateurs ? La question de l'authentification devient centrale : OAuth2, JWT, ou une combinaison des deux ?

Contrairement à ce qu'on lit partout, ce n'est pas un choix binaire. C'est une question d'architecture, de cas d'usage et de vos contraintes métier. Cet article vous aide à y voir clair sans jargon inutile.

OAuth2 : quand la confiance tierce est votre alliée

OAuth2 est un protocole de délégation. Son objectif : permettre à un utilisateur de donner accès à ses données sans partager son mot de passe. Un exemple concret : votre client WooCommerce qui se connecte à votre API métier via ses identifiants Google ou Microsoft.

OAuth2 fonctionne ainsi :

  • L'utilisateur clique sur « Se connecter avec Google »
  • Il accepte les permissions demandées sur Google
  • Google envoie un jeton d'accès à votre application
  • Votre API utilise ce jeton pour identifier l'utilisateur

Les vrais avantages pour une PME : vous n'avez pas à gérer les mots de passe des utilisateurs, vous pouvez révoquer l'accès instantanément, et c'est plus sûr (le fournisseur d'identité gère la sécurité).

Mais attention : OAuth2 est lourd. Il nécessite des appels réseau à un serveur d'authentification, ce qui ajoute de la latence. Pour une API interne à forte charge, ce n'est pas optimal.

JWT : la légèreté au prix de la statelessness

JWT (JSON Web Token) est un format de jeton, pas un protocole. C'est une chaîne encodée contenant des données (claims) signées cryptographiquement. Un exemple : un jeton qui dit « cet utilisateur a l'ID 42 et les droits admin ».

Comment ça marche :

  • L'utilisateur se connecte avec un mot de passe
  • Votre serveur génère un JWT (signé avec une clé secrète)
  • Le client stocke ce JWT et l'ajoute à chaque requête
  • Votre API valide la signature sans appel externe

L'avantage majeur : aucun appel réseau pour valider le jeton. C'est rapide, scalable, et parfait pour une architecture microservices. Votre serveur stateless peut traiter des milliers de requêtes sans état partagé.

Le piège : le serveur ne peut pas révoquer un JWT avant son expiration. Si un utilisateur quitte votre entreprise et que son jeton expire dans 8 heures, il gardera l'accès. Vous devez donc prévoir une liste noire (blacklist) des jetons révoqués, ce qui remet un peu d'état côté serveur.

Quelle stratégie pour votre cas d'usage ?

Vous exposez une API interne ou B2B

Optez pour JWT avec une courte expiration (15-30 minutes). Combiné à un refresh token (plus long, 7 jours), vous obtenez sécurité et performance. Ce modèle est standard pour les applications métier avec fort volume.

Vous intégrez vos utilisateurs externes (clients, partenaires)

OAuth2 avec un fournisseur d'identité (Google, Microsoft, ou une solution comme Keycloak). Les utilisateurs gardent leurs identifiants habituels, et vous n'avez jamais accès à leurs mots de passe. C'est le standard pour les SaaS modernes.

Vous avez un plugin WooCommerce ou un module métier à sécuriser

JWT est votre ami. WooCommerce génère des jetons simples, vous pouvez les valider rapidement dans votre API, et aucune dépendance externe n'entrave la performance.

Vous automatisez des tâches métier

Pour les scripts d'automatisation et les tâches planifiées, OAuth2 peut être complexe. JWT avec une clé API dédiée (ou un jeton machine-to-machine) est plus simple. Si vous utilisez Dolibarr, les clés API natives suffisent souvent.

Les erreurs à éviter

Choisir JWT sans penser à la révocation. Si vos utilisateurs doivent perdre l'accès rapidement (départ, changement de rôle), prévoyez un système de cache ou une blacklist pour les jetons révoqués.

Stocker le JWT en localStorage dans une app web. C'est vulnérable aux attaques XSS. Utilisez un cookie httpOnly et SameSite pour votre frontend.

Négliger la signature du JWT. Un JWT non signé n'a aucune valeur. Toujours utiliser RS256 (RSA) ou HS256 (HMAC) avec une clé suffisamment longue.

Oublier le HTTPS. Que vous utilisiez OAuth2 ou JWT, sans HTTPS, l'authentification ne vaut rien. C'est non négociable.

En pratique : la combinaison gagnante

La plupart des architectures modernes mixent les deux :

  • OAuth2 pour l'authentification initiale : l'utilisateur se connecte avec une identité tierce (ou votre propre serveur OAuth2).
  • JWT pour les appels API : en échange, vous remettez un JWT court (15 min) et un refresh token long (7 jours). L'utilisateur appelle l'API avec le JWT ; quand il expire, il utilise le refresh token pour en obtenir un nouveau sans re-saisir ses identifiants.

C'est rapide, sécurisé et flexible. Les grandes entreprises tech fonctionnent comme ça.

Audit de votre stratégie actuelle

Si vous n'êtes pas certains de votre implémentation, un audit de sécurité API vaut le coup. On cherche :

  • Les jetons sont-ils signés correctement ?
  • La durée de vie est-elle appropriée ?
  • Comment gérez-vous la révocation ?
  • Les données sensibles sont-elles exposées dans le jeton ?
  • Votre HTTPS est-il bien configuré ?

Ces questions techniques ont des impacts métier : une faille d'authentification, c'est potentiellement l'accès à vos données client, vos tarifs, vos processus métier.

Si vous êtes face à un choix d'architecture ou à des doutes sur votre implémentation, n'hésitez pas à nous contacter. Planéo Dev peut vous aider à auditer et structurer votre stratégie d'authentification, que ce soit pour une API interne, un SaaS ou une intégration métier.

La bonne nouvelle ? Il n'y a pas une réponse unique. Il y a une réponse pour votre contexte. Et c'est celle-là qu'il faut choisir.

Questions fréquentes

OAuth2 est un protocole de délégation d'accès (comment obtenir la permission d'accéder aux données de quelqu'un d'autre). JWT est un format de jeton (une façon d'empaqueter et de signer des données). On peut utiliser JWT *dans* OAuth2. Ils ne sont pas concurrents, ils répondent à des problèmes différents.

Techniquement, un JWT ne peut pas être révoqué avant son expiration naturelle (c'est par conception). Mais vous pouvez maintenir une « blacklist » de jetons révoqués côté serveur. C'est un trade-off : quelques secondes de latence pour la révocation, en échange d'une API ultra-rapide.

Dans une application web, vous pouvez stocker le JWT dans un cookie httpOnly et SameSite. Le navigateur envoie automatiquement le cookie avec chaque requête, et c'est plus sûr que localStorage (protégé contre XSS). Sur mobile, vous stockez généralement le JWT en mémoire ou dans un stockage sécurisé.