Qu'est-ce qu'un bearer token ? Définition, JWT et sécurité

Qu'est-ce qu'un bearer token ?

Un bearer token (jeton au porteur) est un justificatif d'accès qui donne les droits qu'il couvre à quiconque le présente. Il est défini pour OAuth 2.0 dans la RFC 6750 et circule dans l'en-tête HTTP Authorization sous la forme Authorization: Bearer <token>. Le serveur vérifie le jeton et autorise ou refuse la requête. La possession est la seule preuve exigée : un bearer token se protège donc comme un mot de passe.

Comment fonctionne un bearer token

GET /api/users/me HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...

Le serveur valide le jeton en le recherchant, en vérifiant sa signature ou en interrogeant un endpoint d'introspection. Si le jeton est expiré, révoqué ou mal formé, la RFC 6750 prévoit que le serveur réponde 401, avec éventuellement l'erreur invalid_token :

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token"

Le déroulement habituel :

1. Le client s'authentifie, par exemple via un flux OAuth 2.0 ou une connexion.
2. Le serveur d'autorisation renvoie un jeton d'accès (access token), en général en JSON :

   {"access_token": "...", "token_type": "Bearer", "expires_in": 3600}

3. Le client conserve le jeton et l'envoie dans l'en-tête Authorization à chaque appel d'API.
4. L'API contrôle le jeton et ses permissions (scopes) à chaque requête.
5. À l'expiration, le client utilise un refresh token pour en obtenir un nouveau, ou s'authentifie de nouveau.

Les formats de bearer token

Jetons opaques

Une chaîne aléatoire sans information propre. Le serveur conserve sa signification et la consulte à chaque requête ; révoquer un jeton revient donc à supprimer l'enregistrement. Le prix à payer est une consultation par requête.

Authorization: Bearer 7b3f2e8a-1c4d-4b6a-9e7f-2c8d3a4b5e1f

JWT (JSON Web Tokens)

Un JWT (RFC 7519) est un jeton signé et autonome : header.payload.signature, chaque partie encodée en Base64URL. Le payload contient des claims comme l'utilisateur, les scopes et l'expiration, et l'API peut vérifier la signature sans accès à une base de données. La contrepartie, c'est la révocation : un JWT reste valide jusqu'à son expiration, sauf à tenir une liste de blocage. Rappelez-vous que décoder un JWT ne fait que le lire. La confiance vient de la vérification de la signature. Vous pouvez en inspecter un sans risque avec le décodeur JWT.

Bearer token et autres justificatifs

Une clé d'API est souvent envoyée elle aussi comme un bearer token. La différence tient à la durée de vie et à la portée : les jetons d'accès bearer doivent être de courte durée et à portée étroite, ce qui est rarement le cas des clés d'API.

Les flux OAuth 2.0 qui émettent des bearer tokens

• Authorization code avec PKCE. Pour les applications avec utilisateurs : l'utilisateur se connecte chez le fournisseur et l'application échange un code contre des jetons. PKCE protège les clients publics comme les applications mobiles et les applications monopages.
• Client credentials. Pour les appels de serveur à serveur sans utilisateur : l'application s'authentifie avec son client ID et son secret, et reçoit un jeton d'accès.
• Refresh token. Un justificatif plus durable, utilisé uniquement pour obtenir de nouveaux jetons d'accès, avec des règles de stockage plus strictes.
• Device code. Pour les appareils sans navigateur, comme les téléviseurs et les outils en ligne de commande.

Sécurité des bearer tokens

Comme posséder le jeton équivaut à avoir l'accès, un jeton volé fonctionne pour celui qui le détient jusqu'à son expiration.

• Utilisez toujours TLS. La RFC 6750 impose aux clients d'utiliser TLS à chaque envoi d'un bearer token.
• Gardez les jetons hors des URL. La spécification n'admet le paramètre de requête access_token que si l'en-tête et le corps sont impossibles, et le déconseille. Les URL finissent dans les journaux et l'historique du navigateur.
• Gardez les jetons d'accès de courte durée et faites tourner les refresh tokens, pour qu'une fuite n'ait qu'une petite fenêtre d'exploitation.
• Demandez le scope le plus étroit. Un jeton qui lit un profil ne devrait pas pouvoir supprimer le compte.
• Validez chaque JWT complètement. Vérifiez la signature avec l'algorithme et la clé que vous avez configurés (jamais avec l'algorithme annoncé dans l'en-tête du jeton), puis contrôlez l'émetteur, l'audience et l'expiration.
• Stockez les jetons avec soin. Les applications mobiles utilisent le trousseau ou le keystore du système, les serveurs un gestionnaire de secrets. Les scripts d'une page web peuvent lire localStorage, ce qui fait du XSS une voie de vol. Détails dans sécurité des API.

Erreurs courantes avec les bearer tokens

• Journaliser l'en-tête Authorization dans les logs d'accès, les proxys ou les outils de suivi d'erreurs.
• Émettre des jetons d'accès valables des jours ou des semaines, qui deviennent alors des clés d'API.
• Accepter un JWT sans vérifier sa signature, son émetteur ou son audience.
• Utiliser un même secret HS256 pour plusieurs services : tout service capable de vérifier les jetons peut aussi en forger.
• Placer le jeton dans une chaîne de requête ou dans le bundle du front-end.

Tester et surveiller des API avec bearer token

L'authentification change la façon de tester une API sous charge :

• L'obtention du jeton est elle-même un endpoint. Si chaque utilisateur virtuel en demande un au départ, vous testez aussi le serveur d'autorisation. Décidez si c'est voulu.
• Les jetons expirent pendant les longs tests. Un test de 30 minutes avec des jetons de 15 minutes demande une logique de renouvellement dans le script.
• Un seul jeton partagé masque les limites et les caches par utilisateur. Un test réaliste utilise un jeton par utilisateur virtuel.
• Vérifiez les cas négatifs : un jeton expiré ou révoqué doit renvoyer 401 rapidement.

Ces points sont détaillés pas à pas dans le guide des tests de performance d'API avec OAuth 2.0 et dans comment tester des API sécurisées par OAuth avec JMeter (articles en anglais). Pour des vérifications en continu, la surveillance d'API de LoadFocus prend en charge les en-têtes, les bearer tokens OAuth et les requêtes enchaînées, et les contrôles s'exécutent toutes les 5 minutes dans l'offre gratuite. Pour rejouer le flux de jetons sous charge, voir les tests de charge JMeter.

Questions fréquentes sur les bearer tokens

Les bearer tokens sont-ils sûrs ?

Ils sont aussi sûrs que la manière dont vous les gérez. Envoyez-les uniquement via TLS, gardez-les de courte durée, limitez leur scope et ne les journalisez jamais. Quiconque obtient un jeton valide peut l'utiliser.

Quelle est la différence entre un bearer token et un JWT ?

Bearer décrit l'usage du jeton : celui qui le présente obtient l'accès. JWT décrit son format : un jeton signé contenant des claims. Un JWT sert souvent de bearer token, mais un bearer token peut aussi être une chaîne aléatoire opaque.

Combien de temps un bearer token doit-il durer ?

Le moins longtemps que votre application le permet : pour un jeton d'accès, en général de quelques minutes à une heure, renouvelé grâce à un refresh token. Plus un jeton vit longtemps, plus une fuite fait de dégâts.

Peut-on révoquer un JWT ?

Pas de lui-même, puisque l'API le vérifie sans interroger personne. Les équipes combinent des durées courtes et la rotation des refresh tokens, une liste de blocage, ou des jetons opaques avec introspection quand la révocation immédiate compte.

Que faire si un jeton est volé ?

Révoquez-le avec son refresh token, changez toute clé de signature susceptible d'être exposée et examinez les journaux d'accès à la recherche d'usages depuis des endroits inattendus.

Comment envoyer un bearer token avec curl ?

Ajoutez l'en-tête : curl -H "Authorization: Bearer VOTRE_TOKEN" https://api.example.com/me. L'outil curl en ligne gratuit permet d'essayer une requête depuis le navigateur.