Quand une application envoie une requête à une API, elle transmet le plus souvent un jeton porteur dans l’en-tête HTTP. Ce terme revient dans toute documentation liée à OAuth 2.0, aux architectures REST ou à la gestion d’identités cloud. Le jeton porteur n’est pas un format de données : c’est un mode de présentation d’un jeton d’accès, et cette nuance change la manière dont on évalue sa sécurité.
Jeton porteur : un mode de possession, pas un format technique
La confusion la plus répandue consiste à traiter le jeton porteur comme un type de jeton au même titre qu’un JWT ou qu’un jeton opaque. En réalité, le mot « bearer » décrit qui peut utiliser le jeton, pas comment il est construit.
A voir aussi : Dans quelles tâches l’IA est-elle mauvaise ?
La RFC 6750, publiée en octobre 2012, définit le cadre d’utilisation des jetons porteurs dans OAuth 2.0. Le principe est simple : toute entité qui détient le jeton peut l’utiliser pour accéder à la ressource protégée, sans fournir de preuve cryptographique supplémentaire.
Un jeton porteur peut donc prendre la forme d’une chaîne opaque (une suite de caractères aléatoires que seul le serveur d’autorisation sait valider) ou d’un JWT signé contenant des informations lisibles côté client. Le serveur de ressources ne demande pas au porteur de prouver son identité au-delà de la présentation du jeton lui-même.
A lire en complément : Comment savoir si un drone me filme ?
Cette caractéristique le distingue des jetons liés, où le client doit démontrer qu’il possède la clé associée au jeton avant d’obtenir l’accès.
Transmission du jeton porteur dans une requête API
Le mécanisme d’utilisation suit un schéma constant. Le client obtient un jeton auprès du serveur d’autorisation via un flux OAuth 2.0, puis le transmet dans l’en-tête HTTP Authorization de chaque requête adressée à l’API :
Authorization: Bearer [chaîne du jeton]
Le serveur de ressources vérifie la validité du jeton (signature, expiration, périmètre d’autorisation) et accorde ou refuse l’accès. Aucune autre donnée d’authentification n’est requise à ce stade.
Pourquoi la transmission par URL pose problème
Certaines implémentations anciennes passaient le jeton dans les paramètres de requête de l’URL. La RFC 9700 publiée en janvier 2025 recommande de ne plus transmettre les jetons dans les URL. Les raisons sont documentées : les URL apparaissent dans l’historique du navigateur, dans les journaux des serveurs web, dans les outils de surveillance réseau et dans l’en-tête Referer transmis aux sites tiers.
Un jeton porteur exposé dans un journal de serveur devient exploitable par quiconque accède à ce journal, parfois des mois après son émission si aucune politique de rotation n’est en place.
Limites de sécurité du modèle porteur et alternatives récentes
Le risque principal du jeton porteur tient à sa nature même : un jeton volé suffit à usurper l’accès. TLS chiffre le jeton pendant le transport, mais une fois le canal déchiffré (côté client, côté serveur, dans un proxy d’entreprise), le jeton redevient une chaîne exploitable.
Plusieurs vecteurs d’interception existent :
- Journaux applicatifs mal protégés qui enregistrent les en-têtes HTTP, y compris le jeton d’accès
- Extensions de navigateur ou logiciels malveillants capables de lire le stockage local ou les cookies non sécurisés
- Fuites via les en-têtes
Refererlorsque le jeton transite par l’URL, malgré les recommandations contraires - Compromission d’un serveur intermédiaire (proxy, passerelle API) où le jeton est temporairement déchiffré
DPoP : lier le jeton à une clé client
La RFC 9449, publiée en septembre 2023, standardise le mécanisme DPoP (Demonstrating Proof of Possession). Le principe consiste à associer le jeton d’accès à une clé cryptographique détenue par le client. À chaque requête, le client génère une preuve qu’il possède la clé privée correspondante.
Un jeton DPoP intercepté ne peut pas être rejoué par un attaquant qui ne dispose pas de la clé privée du client légitime. Le serveur de ressources vérifie à la fois le jeton et la preuve de possession avant d’accorder l’accès.
Le mTLS (mutual TLS) constitue une autre approche : le client présente un certificat lors de l’établissement de la connexion TLS, et le jeton est lié à ce certificat. Les deux mécanismes visent le même objectif, à savoir rendre le jeton inutilisable en dehors du contexte pour lequel il a été émis.
Jeton porteur et JWT : clarifier la relation
Un JWT (JSON Web Token) est un format. Un jeton porteur est un mode d’utilisation. Un JWT peut être un jeton porteur, mais tous les jetons porteurs ne sont pas des JWT.
Quand un serveur d’autorisation émet un JWT comme jeton d’accès, ce JWT contient typiquement des claims (revendications) : l’identité de l’utilisateur, les périmètres d’autorisation accordés, la date d’expiration. Le serveur de ressources peut valider ces informations sans contacter le serveur d’autorisation, ce qui réduit la latence.
Un jeton opaque, à l’inverse, ne contient aucune information lisible côté client. Le serveur de ressources doit interroger le serveur d’autorisation (via un endpoint d’introspection) pour vérifier sa validité. Ce modèle offre un contrôle de révocation plus réactif : dès que le serveur d’autorisation invalide le jeton, la prochaine vérification le détecte.
Le choix entre JWT et jeton opaque dépend du compromis entre performance (validation locale avec JWT) et contrôle (révocation immédiate avec jeton opaque). Les retours terrain divergent sur ce point selon la taille de l’infrastructure et la sensibilité des ressources protégées.
Durée de vie et révocation d’un jeton porteur OAuth 2.0
Un jeton porteur reste valide jusqu’à son expiration ou sa révocation explicite. La durée de vie varie selon l’implémentation : certains serveurs d’autorisation émettent des jetons à durée courte (quelques minutes), d’autres tolèrent des durées plus longues associées à un jeton de rafraîchissement.
- Un jeton à durée courte limite la fenêtre d’exploitation en cas de vol, mais impose des renouvellements fréquents via le refresh token
- Un jeton à durée longue réduit les échanges avec le serveur d’autorisation, mais augmente le risque si le jeton est compromis
- La révocation explicite (endpoint
revoke) permet d’invalider un jeton avant son expiration naturelle, à condition que le serveur de ressources vérifie cette révocation
Les données disponibles ne permettent pas de désigner une durée de vie universellement adaptée. Le dimensionnement dépend du niveau de risque accepté et de la capacité du système à détecter rapidement une compromission.
Le modèle porteur reste le mécanisme d’autorisation API le plus déployé dans les architectures web actuelles. Les travaux récents autour de DPoP et du mTLS ne le remplacent pas encore, mais ils répondent à une limite structurelle : la confiance accordée au seul fait de détenir un jeton, sans vérifier qui le présente.
