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.
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é.
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é ».
Le flux d'un jeton porteur peut être découpé en quelques étapes :
L'utilisateur se connecte
Imaginons que tu te connectes à une application bancaire avec ton identifiant et ton mot de passe.
Le fournisseur d'identité émet un jeton
Une fois vérifié, le serveur d'authentification renvoie un jeton porteur. Cela pourrait ressembler à :
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 :
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).
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.
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.
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.
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.
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 :
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. »
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 :
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.
<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.
Pour éclaircir le tableau, voyons comment les jetons porteurs se comparent aux autres types de jetons courants :
Les jetons porteurs et jetons d'accès ne sont pas des concepts opposés — ils sont liés :
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.
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.
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 :
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.
Pour utiliser en sécurité les jetons porteurs, il est important de suivre les meilleures pratiques. Voici un tour d'horizon avec des exemples :
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.
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.
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.
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.
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.
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.
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é.