Français
  • jetons porteurs
  • jwt

Qu'est-ce qu'un jeton porteur ?

Découvrez ce que sont les jetons porteurs, comment ils fonctionnent dans OAuth 2.0 et JWT, la différence avec les jetons d'accès, et les meilleures pratiques.

Guamian
Guamian
Product & Design

Arrêtez de perdre des semaines sur l'authentification des utilisateurs
Lancez des applications sécurisées plus rapidement avec Logto. Intégrez l'authentification des utilisateurs en quelques minutes et concentrez-vous sur votre produit principal.
Commencer
Product screenshot

Derrière presque chaque connexion à une application moderne ou chaque requête API se cache un discret pilier : le jeton porteur. Tu ne t'en rends peut-être pas compte, mais il est là à chaque fois que tu connectes des services, te connectes, ou récupères des données dans le cloud.

Ce guide t'explique ce que font les jetons porteurs, pourquoi ils sont importants, et comment les manipuler en toute sécurité.

Qu'est-ce qu'un jeton porteur ?

Un jeton porteur est une donnée, généralement une chaîne de caractères, qui prouve que celui qui le détient est autorisé à accéder à une ressource. L'essentiel est que quiconque porte le jeton peut l'utiliser, sans devoir fournir de preuve supplémentaire.

Imagine une carte d'embarquement d'avion. Une fois en ta possession, tu peux passer la sécurité et embarquer dans l'avion. Personne ne te demandera à nouveau ton identité si la carte est valide. De la même façon, un jeton porteur permet à ton application de « monter à bord de l'API » sans vérifier ton identité à chaque fois.

Par exemple, après t'être connecté à Spotify sur ton téléphone, tu n'as pas besoin de saisir ton mot de passe chaque fois que tu veux écouter une chanson. L'application stocke à la place un jeton porteur qui indique aux serveurs de Spotify : « cette requête provient d'un utilisateur autorisé ».

Comment fonctionnent les jetons porteurs en pratique

Le flux d'un jeton porteur peut être découpé en quelques étapes :

  1. L'utilisateur se connecte

    Imaginons que tu te connectes à une application bancaire avec ton identifiant et ton mot de passe.

  2. Le fournisseur d'identité émet un jeton

    Une fois vérifié, le serveur d'authentification renvoie un jeton porteur. Cela pourrait ressembler à :

  1. Le client utilise le jeton

    À chaque fois que tu tapes sur « Consulter le solde » ou « Transférer de l'argent », l'appli inclut le jeton dans la requête HTTP :

  1. L'API le valide

    Le serveur vérifie que le jeton est encore valide, n'a pas expiré, et contient les bonnes permissions (comme read:balance ou write:transfer).

  2. Accès accordé

    Si tout est en ordre, le serveur répond avec les informations demandées.

Ce modèle est largement utilisé dans les services comme les APIs GitHub, où les développeurs s'authentifient avec un jeton porteur plutôt qu'en ressaisissant leurs identifiants à chaque fois.

Pourquoi les jetons porteurs sont-ils devenus populaires ?

Les jetons porteurs se sont imposés car ils résolvaient des problèmes fréquents de sécurité web. Contrairement aux sessions serveur, ils n'imposent pas de stocker des données pour chaque utilisateur connecté. Au lieu de cela, le jeton contient toutes les informations nécessaires au serveur pour valider les requêtes.

Par exemple, dans une architecture microservices où des dizaines de services communiquent entre eux, maintenir un stockage centralisé des sessions serait complexe et peu efficace. Avec les jetons porteurs, chaque service peut valider les requêtes indépendamment, gardant le système léger et évolutif.

Un exemple concret : les APIs de Slack reposent largement sur les jetons porteurs. Quand tu crées un bot Slack, tu obtiens un jeton qui permet à ton bot d'appeler les endpoints Slack, sans devoir maintenir une session utilisateur par utilisateur.

Que contient un jeton porteur ?

De nombreux jetons porteurs sont mis en œuvre comme des JWTs (JSON Web Tokens). Ces jetons sont des chaînes encodées qui incluent des informations sur l'utilisateur et ses permissions.

Décodons un JWT d'exemple :

Voilà ce que cela signifie :

  • sub : L'identifiant unique de l'utilisateur (le sujet).
  • name : Le nom de l'utilisateur.
  • iat : Moment où le jeton a été émis.
  • exp : Date d'expiration (quand il devient invalide).
  • scope : Les permissions ; ici, l'appli peut lire et écrire des messages.

En pratique, si le jeton de Jane avait seulement le scope read:messages, l'application pourrait lire ses messages mais pas en envoyer de nouveaux à sa place.

Jetons porteurs vs. jetons d'accès : quelle différence ?

Il est facile de confondre jetons porteurs et jetons d'accès, car les deux termes reviennent souvent ensemble. En réalité, ils sont liés mais pas identiques.

Jeton d'accès : le « billet de permission »

Un jeton d'accès est un justificatif représentant l'autorisation d'accès d'un utilisateur à une ressource. Il contient des informations comme :

  • Qui est l'utilisateur (son ID)
  • Ce qu'il a le droit de faire (permissions/scopes)
  • La date d'expiration du jeton

On peut le comparer à un billet de permission signé par le directeur de l'école. Il indique au professeur (l'API) que tu es autorisé à partir en excursion (accéder à la ressource).

Par exemple, lorsque tu te connectes à un service de stockage cloud, le système délivre un jeton d'accès avec le scope read:files. Ce jeton indique à l'API de stockage : « Cet utilisateur peut lire les fichiers mais pas les supprimer. »

Jeton porteur : le « format de transmission »

Un jeton porteur est un type particulier de jeton d'accès. Le terme porteur fait référence à la manière dont le jeton est utilisé : quiconque le présente peut s'en servir pour accéder à des ressources, aucune autre preuve d'identité n'est requise.

Autrement dit :

  • Tous les jetons porteurs sont des jetons d'accès.
  • Mais tous les jetons d'accès ne sont pas forcément des jetons porteurs.

Il existe d'autres types de jetons, comme les jetons à détenteur de clé, qui obligent le client à prouver qu'il possède une clé cryptographique en plus du jeton. Les jetons porteurs passent outre cette étape supplémentaire, ce qui les rend plus simples mais aussi plus risqués en cas de vol.

Exemple concret

  • Jeton d'accès (générique) : Peut être une donnée signée, exigeant parfois que le client prouve aussi la possession d'une clé privée.
  • Jeton porteur (spécifique) : La plupart des implémentations OAuth 2.0 aujourd'hui délivrent les jetons d'accès au format porteur. Par exemple, Google OAuth renvoie un jeton d'accès à utiliser dans l'en-tête Authorization: Bearer <token>.

Cela signifie que lorsque tu vois « jeton d'accès » dans les tutoriels OAuth, il s'agit presque toujours d'un jeton porteur, sauf mention contraire.

Comparaison avec d'autres types de jetons

Pour éclaircir le tableau, voyons comment les jetons porteurs se comparent aux autres types de jetons courants :

  • Jeton d'actualisation (refresh token) : Sert à obtenir un nouveau jeton d'accès quand l'ancien expire. Les jetons d'actualisation ne sont généralement pas des jetons porteurs, car ils sont échangés de manière sécurisée avec le serveur d'autorisation, et non envoyés directement aux APIs.
  • Jeton d'identité (ID token) : Sert à l'authentification, pas à l'autorisation. Il transporte des informations sur l'identité utilisateur (email, nom, ID utilisateur, etc.). Selon le système, un ID token peut aussi être un jeton porteur, mais son rôle est différent de celui d'un jeton d'accès.
  • Clé API (API key) : Forme d'identification plus simple qui identifie l'application appelante. Bien souvent, une clé API agit comme un jeton porteur : quiconque la possède peut appeler l'API.

Les jetons porteurs et jetons d'accès ne sont pas des concepts opposés — ils sont liés :

  • La plupart des jetons d'accès sont des jetons porteurs.
  • Un jeton porteur décrit la façon dont un jeton est utilisé (le présenter pour accéder).
  • Dans la vie courante, les termes « jeton d'accès » et « jeton porteur » sont souvent utilisés de manière interchangeable, bien que techniquement ils soulignent des aspects différents.

Comment valider un jeton d'accès JWT (Jeton porteur)

La validation d'un jeton porteur protège ton API contre les accès non autorisés. Si tes jetons sont des JWTs, cette validation est rapide et se fait localement. L'API peut vérifier le jeton sans appeler l'émetteur à chaque fois.

L'idée principale

  1. Décoder le jeton.
  2. Vérifier la signature avec la clé publique de l'émetteur.
  3. Contrôler les champs standards comme issuer, audience, expiration, not-before.
  4. Appliquer les règles de ton application (scopes, rôles, type de jeton).
  5. Optionnellement, consulter une liste de révocation ou l'état de session pour les actions sensibles.

Liste de vérification de validation (JWT)

Utilise-la comme check-list lors de l'intégration d'une gateway API ou d'un middleware.

  • Signature

    Vérifie la signature en utilisant l'algorithme précisé dans l'entête (par exemple RS256). Récupère l'endpoint JWKS de l'émetteur, choisis la clé correspondant au kid, et mets-la en cache.

  • Issuer (iss)

    Fais correspondre le iss du jeton avec l'URL de ton émetteur de confiance, exactement et avec le bon protocole.

  • Audience (aud)

    Assure-toi que le jeton était destiné à ton API. Compare-le à ton identifiant d'API (ex. : https://api.example.com ou une chaîne d'audience).

  • Expiration (exp) et Not-Before (nbf)

    Rejette les jetons expirés. Respecte nbf pour qu'un jeton ne puisse pas être utilisé avant son heure de début. Prévoyez une faible marge de décalage d'horloge (30 à 60 secondes).

  • Issued-At (iat)

    Utile pour le debug et pour rejeter les vieux jetons dans un contexte strict.

  • Type de jeton

    Confirme qu'il s'agit bien d'un jeton d'accès. Certains fournisseurs incluent typ : "at+jwt" ou similaire. N'accepte pas d'ID tokens pour accéder aux APIs.

  • Scopes / permissions

    Lis le scope ou les claims spécifiques au fournisseur (ex : permissions, rôles). Applique le principe du moindre privilège à chaque endpoint.

  • Subject (sub)

    L'identifiant stable de l'utilisateur ou du client. Utilise-le pour associer des ressources ou à des fins d'audit.

  • Anti-rejeu et révocation (optionnel mais conseillé)

    Pour les endpoints sensibles, vérifie une denylist temporaire des valeurs jti, ou valide une session active. Cela aide en cas de déconnexion ou de compromission suspectée.

Risques de sécurité des jetons porteurs

Puisque les jetons porteurs fonctionnent sur le principe « quiconque le détient peut l'utiliser », ils doivent être traités comme des clés de maison. Si quelqu'un vole ta clé, il pourra entrer chez toi tant que tu n'as pas changé la serrure.

Parmi les risques fréquents :

  • Vol de jeton : Si un pirate obtient accès au localStorage du navigateur où le jeton est stocké, il peut se faire passer pour l'utilisateur. Par exemple, en 2018, des extensions de navigateur ont été surprises à voler des jetons stockés dans le localStorage et à les revendre.
  • Attaques par rejeu : Un attaquant qui intercepte un jeton peut le réutiliser tant qu'il n'expire pas. Sans HTTPS, c'est étonnamment facile.
  • Jetons longue durée : Un jeton valable pendant plusieurs semaines ou mois allonge la fenêtre de tir des attaquants.

Des failles réelles se sont produites lorsque des développeurs ont accidentellement publié des jetons porteurs dans des dépôts GitHub publics. Les attaquants peuvent scanner ces jetons et en abuser immédiatement pour accéder sans autorisation.

Meilleures pratiques pour utiliser les jetons porteurs

Pour utiliser en sécurité les jetons porteurs, il est important de suivre les meilleures pratiques. Voici un tour d'horizon avec des exemples :

  1. Toujours utiliser HTTPS

    Imagine envoyer un jeton en clair sur le Wi-Fi public d'un café. N'importe qui espionnant le réseau pourrait copier le jeton et se connecter à ta place.

  2. Utiliser des jetons d'accès à durée de vie courte

    La plupart des plateformes émettent des jetons valables moins d'une heure. Par exemple, les jetons OAuth de Google durent typiquement une heure avant qu'un renouvellement soit nécessaire.

  3. Gérer prudemment les jetons d'actualisation

    Un jeton d'actualisation (refresh) peut demander de nouveaux jetons d'accès sans que l'utilisateur doive se reconnecter. Mais il doit être stocké en sécurité (ex : base de données chiffrée côté serveur), pas côté client.

  4. Limiter les scopes au strict nécessaire

    Si ton appli n'a besoin que de lire l'agenda utilisateur, ne demande pas l'accès en écriture. Cela réduit les dégâts si un jeton est compromis.

  5. Révoquer les jetons au besoin

    De nombreuses apps SaaS permettent aux utilisateurs de consulter les sessions actives et de les révoquer. GitHub, par exemple, permet de révoquer tout jeton d'accès personnel à tout moment.

  6. Surveiller les usages

    La journalisation de l'utilisation des jetons permet de repérer des activités suspectes. Si un même jeton est utilisé de Londres puis de New York à quelques minutes d'intervalle, c'est suspect.

Jetons porteurs et autres méthodes d’authentification

Il est utile de comparer les jetons porteurs à d'autres approches populaires :

  • Cookies & Sessions

    Les sites traditionnels reposent sur des sessions stockées côté serveur, identifiées par un cookie. Cela fonctionne bien pour les sites web, moins pour les APIs ou applis mobiles. Par exemple, la connexion Facebook sur desktop s'appuie sur les cookies, mais ses APIs mobiles utilisent des jetons.

  • Clés API

    Une clé API est une chaîne statique qui authentifie l'application mais pas l'utilisateur. Par exemple, une appli météo utilisera une clé API pour obtenir des données, mais cette clé ne précise pas quel utilisateur demande la météo. Les jetons porteurs peuvent transporter des données utilisateur, ce qui les rend plus polyvalents.

  • TLS mutuel (mTLS)

    Certains systèmes très sécurisés utilisent des certificats à la fois côté client et serveur. Plus sécurisé, mais complexe à déployer à l'échelle. Pour la plupart des plateformes SaaS, les jetons porteurs offrent le bon compromis entre sécurité et simplicité.

À retenir

  • Les jetons porteurs sont simples mais puissants : quiconque les détient peut accéder à la ressource.
  • Ils sont largement utilisés dans les flux OAuth 2.0 et OIDC, particulièrement pour les APIs et applis mobiles.
  • La sécurité dépend de leur gestion : durée de vie courte, scopes précis, HTTPS et révocation sont essentiels.
  • Ils ne sont pas toujours le meilleur choix, mais dans la plupart des contextes SaaS et API, ils offrent le bon équilibre entre sécurité et convivialité.