IT Glossary
Un jeton d'accès est le justificatif qu'un client OAuth 2.0 présente à une API, avec scopes et durée fixés. Différence avec l'ID token et le refresh token.
November 2, 2026
Un jeton d'accès (access token) est un justificatif qu'un client OAuth 2.0 présente à une API pour atteindre des ressources protégées, et qui représente une autorisation précise : quels scopes ont été accordés, à quelle application, pour combien de temps. Le serveur d'autorisation le délivre après le consentement d'un utilisateur ou d'un administrateur. Le jeton peut être une chaîne opaque ou un JSON Web Token, et sa durée de vie est en général courte.
OpenID Connect ajoute un ID token au flux OAuth, et les deux sont souvent confondus parce qu'ils peuvent tous deux être des JWT. L'ID token s'adresse à l'application cliente : il prouve qui s'est connecté et quand, pour ouvrir une session. Le jeton d'accès s'adresse à l'API : il porte l'autorisation, pas l'identité. Envoyer un ID token à une API, ou lire l'identité de l'utilisateur dans un jeton d'accès que le client devrait traiter comme opaque, sont deux erreurs d'intégration classiques.
La RFC 6749, publiée en octobre 2012, décrit les jetons d'accès comme des justificatifs qui représentent des scopes et des durées d'accès précis. Pour la gouvernance, c'est la définition utile : la permission d'une application tierce est l'ensemble des scopes de son jeton. Un salarié junior peut accorder la lecture de toute sa messagerie et de son drive, un administrateur peut accorder des scopes valables pour toute l'organisation. Côté RGPD, ces scopes indiquent aussi à quelles données personnelles l'application tierce accède.
Un cabinet de conseil de 300 personnes travaille sur Google Workspace. Une responsable commerciale se connecte à un outil IA de prise de notes avec son compte Google et accepte qu'il lise et gère son agenda et sa messagerie. L'outil détient désormais des jetons d'accès avec ces scopes et appelle les API Google en son nom. Son poste, son équipe ou son ancienneté n'y changent rien : ce sont les scopes qui décident de ce que l'outil peut lire.
La découverte SaaS de Corma fait entrer ce type d'outil dans l'inventaire, avec ses utilisateurs, son responsable et son coût, dans le cadre de la visibilité sur le shadow IT et le shadow AI. Les revues d'accès demandent ensuite au responsable de chaque application de confirmer qui doit garder l'accès, tandis que les scopes eux-mêmes se vérifient et se retirent dans la console d'administration Google Workspace.
Non. Un jeton d'accès est délivré par un serveur d'autorisation pour des scopes précis et une durée limitée. Une clé API est un secret statique, créé une fois et valide jusqu'à sa révocation.
Le serveur d'autorisation fixe sa durée de vie au moment de l'émission. Les jetons d'accès sont en général de courte durée, et l'application en obtient de nouveaux grâce au refresh token.
Parfois. Beaucoup de serveurs d'autorisation émettent des jetons d'accès au format JWT, d'autres des chaînes opaques que seul le serveur sait interpréter.
Oui, si le serveur d'autorisation prend en charge la révocation et que l'API la vérifie. Un JWT autonome reste en général valide jusqu'à son expiration, l'une des raisons pour lesquelles les jetons d'accès vivent peu de temps.
