JWT vs OAuth : Principales différences, fonctionnement conjoint et bonnes pratiques

Si tu débutes avec l’authentification et que tu développes une application qui gère des connexions, des paiements ou des données utilisateur, tu as probablement rencontré les termes JWT et OAuth. Ils peuvent sembler complexes, réservés au « backend », mais ce ne sont pas uniquement des sujets pour les ingénieurs en sécurité.

Avec les API, les intégrations tierces et les technologies émergentes comme l’IA, le MCP, et les systèmes à base d’agents, ces deux-là jouent un rôle direct dans la convivialité, la sécurité et l’évolution de ton produit. Comprendre les bases te permet de :

• Concevoir des fonctionnalités sécurisées dès le début
• Communiquer efficacement avec ton équipe technique
• Prendre de meilleures décisions produit concernant l’authentification et les parcours utilisateurs
• Éviter les erreurs de sécurité coûteuses qui minent la confiance des utilisateurs

Par exemple, dans la dernière spécification MCP, le système d’autorisation s’appuie sur des standards éprouvés :

• OAuth 2.1 IETF Draft (draft-ietf-oauth-v2-1-13)
• OAuth 2.0 Metadata du serveur d’autorisation (RFC8414)
• OAuth 2.0 Protocole d’enregistrement dynamique du client (RFC7591)
• OAuth 2.0 Metadata des ressources protégées (RFC9728)

Pourquoi c’est important#

Même si tu n’écris jamais de code backend :

• Les développeurs apprennent à sécuriser les API, à gérer les sessions, et à intégrer des services tiers.
• Les chefs de produit acquièrent le vocabulaire nécessaire pour discuter des flux de connexion, des intégrations et de la conformité avec les équipes et partenaires.
• Les fondateurs et les équipes en démarrage évitent de construire des systèmes de connexion fragiles qui cassent lors des intégrations ou te laissent vulnérables aux failles.

JWT vs OAuth : Les deux concepts clés#

JWT (JSON Web Token) et OAuth (Open Authorization) sont souvent utilisés ensemble, mais servent des objectifs différents.

Vois ça comme ceci :

• OAuth est la façon dont tu donnes les clés à quelqu’un, mais seulement pour les pièces auxquelles il a le droit d’accéder.
• JWT est la carte d’identité qu’il porte, preuve de qui il est et de ce qu’il peut faire.

Dans la section suivante, on va les disséquer côte à côte pour que tu voies clairement les différences et comment ils se complètent.

C’est quoi OAuth 2.0 ?#

OAuth 2.0 est un cadre d’autorisation largement adopté qui permet à une application (le client) d’accéder aux ressources d’un utilisateur avec des permissions limitées, sans avoir à partager les identifiants de l’utilisateur (comme les mots de passe).

Rôles principaux dans OAuth#

• Client : L’application qui demande l’accès.
• Propriétaire de la ressource : Habituellement l’utilisateur, qui donne l’autorisation.
• Serveur d’autorisation : Émet les jetons d’accès après autorisation.
• Serveur de ressource : Héberge les ressources protégées et valide les jetons

Types de grants OAuth courants (Flows)#

• Authorization Code Grant : Le plus sécurisé et recommandé, surtout avec PKCE pour les applis web, SPA et mobiles.
• Implicit Grant : Désormais déconseillé dans OAuth 2.1 pour des raisons de sécurité.
• Resource Owner Password Credentials (ROPC) : Échange direct du login/mot de passe contre un jeton ; moins sécurisé.
• Client Credentials Grant : Pour la communication serveur à serveur ou machine à machine.
• Device Flow : Pour les appareils sans clavier (par ex. smart TV), l’utilisateur autorise depuis un second appareil.

C’est quoi un JWT (JSON Web Token) ?#

Un JWT est un standard ouvert (RFC 7519) pour transmettre des revendications (claims) de manière sécurisée entre deux parties, dans un format compact et sûr pour les URL.

Structure d’un JWT#

Un JWT se compose de trois parties encodées en base64url, séparées par des points (.):

1. Header : Spécifie l’algorithme (par ex. HS256, RS256) et le type de jeton (JWT).
2. Payload : Contient les claims, comme :
   • iss (émetteur)
   • sub (sujet, par ex. ID utilisateur)
   • aud (audience)
   • exp (expiration)
   • Claims personnalisés au besoin
3. Signature – Permet de vérifier que le jeton n’a pas été modifié.

Exemple :

Un exemple de JWT#

Voici un exemple de JWT typique sous forme encodée, avec sa structure décodée afin que tu voies à quoi correspond chaque partie.

JWT Encodé (Base64URL)

Ceci est constitué de trois parties séparées par des points : header.payload.signature

Structure décodée

• Header

• Payload

La charge utile contient des claims

• Signature

La signature garantit que le jeton n’a pas été altéré.

Caractéristiques clés#

• Autonome : Toutes les informations nécessaires sont dans le jeton.
• Sans état : Aucun stockage de session côté serveur nécessaire.
• Signé : (et optionnellement crypté) pour garantir l’authenticité.

JWT vs OAuth : Différences fondamentales#

En résumé :

• JWT est le contenant : comme un passeport avec des détails d’identité.
• OAuth est le système : comme le contrôle à l’immigration, qui décide qui a le passeport et à quoi il peut accéder.

Quand utiliser uniquement le JWT#

Utilise uniquement le JWT quand :

• Authentification mono-système où ton app délivre et vérifie les jetons sans prestataire d’identité externe.
• Gestion de session sans état pour valider l’identité sans stocker de session côté serveur.
• Authentification d’API simple pour des API internes qui n’ont besoin que de vérifier des droits basiques sans consentement complexe.
• Validation performante où les serveurs de ressources valident les jetons localement sans demander au serveur d’authentification.

Exemple :

Une SPA et une API backend que tu possèdes. L’API délivre un JWT contenant sub (ID utilisateur), role, et exp (expiration).

Quand utiliser uniquement OAuth#

Utilise OAuth sans JWT quand :

• Tu n’as pas besoin de jetons autonomes, et des jetons opaques nécessitant une vérification côté serveur sont suffisants.
• Tu veux que le serveur de ressources vérifie à chaque fois auprès du serveur d’autorisation avant d’accorder l’accès.
• Tu es dans un contexte hérité ou réglementé où JWT n’est pas adapté.
• Le but est une délégation d’autorisation pour accorder un accès limité à des applis tierces de manière sécurisée.

Exemple :

Une API qui émet des jetons d’accès opaques et valide chaque requête auprès du serveur d’autorisation.

Quand utiliser à la fois JWT et OAuth#

Utilise-les ensemble quand :

• Tu as plusieurs services ou API et tu veux OAuth pour le flux sécurisé et JWT pour les jetons vérifiables entre services.
• Tu proposes la connexion tierce type « Connexion avec Google » où OAuth gère le consentement et où JWT transporte le jeton d’accès ou d’identité.
• Tu utilises une architecture microservices où chaque service valide les JWT en local.
• Tu as besoin de l’évolutivité du modèle de délégation OAuth et la validation sans état du JWT.

Exemple :

Ton app permet la connexion avec Google. OAuth gère l’autorisation, Google délivre un JWT access token, et tes API le vérifient localement avant de retourner les données.

Comment JWT et OAuth fonctionnent ensemble#

Dans les dispositifs modernes d’authentification/autorisation :

1. OAuth gère le flux d’autorisation.
2. Le serveur d’autorisation délivre un token d’accès ; souvent un JWT.
3. Le JWT est envoyé avec les requêtes aux API pour prouver l’identité et les permissions.

Jetons spéciaux dans OAuth#

• ID token: Utilisé dans OpenID Connect pour prouver l’identité de l’utilisateur ; toujours un JWT.
• Access token: Peut être un JWT ou un jeton opaque.

Bonnes pratiques pour utiliser JWT et OAuth#

• Utilise HTTPS pour protéger les tokens en transit.
• Définis des durées courtes d’expiration pour les JWT ; utilise des refresh tokens pour des sessions plus longues.
  • https://auth.wiki/offline-access.
• Valide la signature avant de faire confiance à un jeton.
• Vérifie le claim aud pour t’assurer que le jeton est destiné à ton application.
• Évite de stocker les tokens dans le localStorage si XSS est un risque ; préfère les cookies sécurisés.

En résumé#

• OAuth 2.0 définit comment obtenir et utiliser les jetons.
• JWT définit à quoi ressemble le jeton et la façon dont il transporte l’information.
• Ils sont complémentaires, pas interchangeables.

La plupart des API modernes utilisent OAuth pour les flux d’autorisation, et JWT pour représenter les jetons. Comprendre les deux t’aidera à concevoir des systèmes d’authentification sécurisés et évolutifs.