Jeton ID ou jeton d’accès : la différence essentielle d’OpenID Connect

By Mirko Peters · 2026-10-28

Découvrez les différences essentielles entre les jetons ID et les jetons d’accès dans OpenID Connect, et comprenez pourquoi les confondre crée de graves failles de sécurité.

Automatically translated with AI from the original post. Read the English original

Comprendre la distinction entre un jeton ID et un jeton d’accès est indispensable pour les développeurs et les administrateurs informatiques qui travaillent avec l’authentification moderne. Si OAuth 2.0 gère les autorisations, OpenID Connect introduit le jeton ID pour confirmer l’identité de l’utilisateur. Confondre ces deux jetons distincts conduit à de graves vulnérabilités de sécurité dans les applications cloud.

Points clés

• Les jetons ID prouvent l’identité d’un utilisateur, tandis que les jetons d’accès accordent l’autorisation et les droits.
• Confondre ces deux jetons est l’une des erreurs principales dans la sécurité des applications développées en interne.
• OpenID Connect ajoute la confirmation d’identité au-dessus du cadre OAuth 2.0.
• Les jetons d’accès peuvent être révoqués, ce qui offre une posture de sécurité plus sûre que le stockage de mots de passe.
• Les applications doivent vérifier cryptographiquement les jetons ID entrants plutôt que de leur faire aveuglément confiance.

Le dilemme central : identité ou autorisation

Dans l’évolution des applications web modernes, les développeurs se heurtent fréquemment à la confusion entre la manière dont les utilisateurs se connectent et la façon dont ces mêmes utilisateurs interagissent avec les données sous-jacentes. Cette confusion vient en grande partie d’une terminologie qui se chevauche dans le domaine de l’identité. Lorsque les applications ont commencé à se multiplier rapidement sur le web, le recours exclusif aux simples couples nom d’utilisateur et mot de passe a créé un énorme goulot d’étranglement en matière de sécurité. Les utilisateurs, épuisés de devoir gérer des dizaines d’identifiants distincts, ont fini par réutiliser leurs mots de passe faibles sur plusieurs plateformes.

Pour résoudre une partie de ce problème, OAuth 2.0 a fait son apparition. Pourtant, OAuth 2.0 n’a jamais été conçu pour répondre à la question de l’identité d’une personne. Sa vocation est de délivrer des autorisations, appelées jetons d’accès, qui permettent à une application d’atteindre des points de terminaison de données spécifiques au nom d’un utilisateur. Un jeton d’accès précise ce qu’une application peut faire, mais reste totalement muet sur l’identité de la personne qui le détient. Cette lacune fondamentale a obligé les entreprises qui souhaitaient mettre en place une expérience d’authentification unique à greffer leurs propres contrôles d’identité sur OAuth, ce qui a donné naissance à des implémentations fragmentées qui s’accordaient rarement entre elles.

OpenID Connect a comblé exactement cette lacune en introduisant une couche standardisée dédiée à l’authentification. En utilisant un second jeton aux côtés du jeton d’accès traditionnel, OpenID Connect sépare clairement la question de l’identité de celle des autorisations. Maintenir ces deux notions distinctes est, aujourd’hui, le changement de mentalité le plus important pour quiconque conçoit ou audite des applications cloud.

Anatomie du jeton ID : ce qui se trouve à l’intérieur

Lorsqu’un utilisateur clique sur le bouton « Se connecter avec Microsoft », le fournisseur d’identité traite les identifiants, gère les exigences d’authentification multifacteur et renvoie finalement l’utilisateur vers l’application, accompagné d’un jeton ID. Ce jeton est structuré sous forme de JSON Web Token, couramment abrégé en JWT et prononcé « jot ». À première vue, un JWT ressemble à une chaîne de caractères impénétrable et séparée par des points. Pourtant, une fois décodée, sa structure interne est remarquablement simple.

À l’intérieur d’un jeton ID, vous trouverez un ensemble restreint de revendications standard, chacune ayant un rôle précis :

• Émetteur : identifie le fournisseur d’identité précis (comme Microsoft Entra ID) qui a généré et signé le jeton.
• Sujet (sub) : Sert d’identifiant unique et immuable de l’utilisateur. Point essentiel : il est conçu pour ne pas changer, même si l’utilisateur modifie son nom d’affichage ou son adresse e-mail.
• Audience (aud) : Indique l’application exacte pour laquelle le jeton a été créé, garantissant qu’un jeton destiné à une application ne puisse pas être intercepté malveillamment et réutilisé par une autre.
• Horodatages : Précisent la date d’émission du jeton, sa date d’expiration et le moment exact où l’utilisateur s’est authentifié.
• Nonce : Joue le rôle d’un numéro de reçu sécurisé qui rattache le jeton obtenu à la session de connexion spécifique à l’origine de la demande, bloquant ainsi efficacement les attaques par rejeu.

Point essentiel : l’ensemble du jeton est signé à l’aide de la clé privée du fournisseur. L’application réceptrice valide cette signature à l’aide de la clé publique correspondante publiée par le fournisseur. Sans cette vérification cryptographique, un jeton ID n’est rien de plus qu’une note non vérifiée échangée entre les parties.

Le danger de confondre identité et accès

L’un des anti-patterns les plus dangereux du développement applicatif consiste à traiter un jeton ID comme une clé d’autorisation. Comme un jeton ID confirme qu’un utilisateur est bien John Doe d’une organisation donnée, les développeurs débutants commettent parfois l’erreur d’utiliser cette confirmation pour accorder des droits d’administration ou un accès illimité à la base de données. Cela revient à méconnaître fondamentalement l’architecture.

Un jeton ID indique simplement qui se tient devant la porte d’entrée ; il ne dit rien de l’autorisation d’ouvrir toutes les pièces intérieures ou de cliquer sur tel bouton d’administration. La logique d’autorisation doit être gérée séparément par l’application, à l’aide du contrôle d’accès basé sur les rôles (RBAC) ou de mécanismes similaires, en prenant l’identité vérifiée comme point de départ plutôt que comme décision d’autorisation définitive.

Par ailleurs, les applications commettent fréquemment l’erreur d’accepter des jetons ID entrants sans effectuer de contrôles de validation appropriés. Faire confiance à un jeton aveuglément, simplement parce qu’une bibliothèque l’a traité en coulisses, expose les systèmes à des données falsifiées. Valider la signature, vérifier les horodatages d’expiration et contrôler la revendication d’audience sont des étapes indispensables au maintien d’un niveau de sécurité satisfaisant.

Conclusion

Maîtriser la frontière entre identité et autorisation contribue à démystifier l’architecture cloud moderne. En réservant strictement les jetons ID à la preuve de l’identité de la personne qui se trouve derrière le clavier, et en laissant aux jetons d’accès le soin de régir les actions autorisées, les développeurs peuvent concevoir des intégrations robustes et sécurisées avec des plateformes comme Microsoft Entra ID. Pour écouter une présentation complète de ces concepts et découvrir le fonctionnement des processus de connexion modernes au sein de l’écosystème Microsoft, consultez la discussion complète. Écoutez l’épisode complet et approfondissez dès aujourd’hui les mécanismes de l’identité dans le cloud !

Questions fréquentes

Un jeton ID peut-il être utilisé pour appeler des API ou accéder à des ressources protégées ?

Non. Un jeton ID ne contient que des revendications d’identité sur l’utilisateur. Pour appeler des API ou accéder à des ressources protégées, une application doit utiliser un jeton d’accès émis via OAuth 2.0.

Pourquoi OpenID Connect et OAuth 2.0 utilisent-ils des jetons distincts ?

Séparer l’identité de l’autorisation permet aux applications de vérifier qui se connecte, sans pour autant donner à cette application un pouvoir illimité de manipuler les données ou les ressources sous-jacentes de l’utilisateur.

Que se passe-t-il si une application accepte un jeton ID sans vérifier sa signature ?

Ne pas vérifier la signature expose l’application à des jetons falsifiés, puisque n’importe qui pourrait générer une chaîne personnalisée se faisant passer pour un utilisateur valide.

Où intervient la valeur « nonce » dans l’échange de jetons ?

Le nonce est une chaîne aléatoire générée au début du processus de connexion et intégrée au jeton ID, ce qui permet à l’application de se prémunir contre les attaques par rejeu.