Différences entre le jeton d'identité et le jeton d'accès dans OAuth2

Imaginez-vous dans un monde où la sécurité et l'accès aux ressources numériques dépendent de la gestion de petits morceaux de données appelés jetons. Dans ce monde, deux types de jetons jouent un rôle central : le jeton d'identité (ID token) et le jeton d'accès (access token), tous deux essentiels dans le processus d'authentification et d'autorisation dans OAuth2, un protocole largement utilisé pour permettre aux utilisateurs de partager leurs informations avec des tiers en toute sécurité, sans avoir à divulguer leurs identifiants.

Mais quelle est réellement la différence entre ces deux jetons ? Pourquoi avons-nous besoin de deux jetons distincts pour accomplir une tâche qui semble relativement simple : prouver l'identité et accorder l'accès aux ressources ?

La réponse se trouve dans la manière dont ces jetons sont utilisés et leur rôle spécifique dans le processus. Commençons par l'essentiel : le jeton d'identité est principalement utilisé pour confirmer que l'utilisateur est bien celui qu'il prétend être. Il contient des informations spécifiques à l'utilisateur, telles que son nom, son adresse e-mail, et toute autre donnée nécessaire pour authentifier son identité. Ce jeton est émis par le fournisseur d'identité, comme Google ou Facebook, une fois que l'utilisateur a correctement prouvé son identité via un processus d'authentification.

D'un autre côté, le jeton d'accès est ce qui permet à l'utilisateur d'accéder aux ressources protégées. Contrairement au jeton d'identité, il ne contient pas de détails sur l'utilisateur lui-même. Au lieu de cela, il informe le serveur de ce à quoi l'utilisateur est autorisé à accéder. Par exemple, si un utilisateur se connecte à une application tierce via son compte Google, le jeton d'accès lui permettra d'accéder à ses e-mails ou à son calendrier, mais uniquement dans les limites définies par le jeton d'accès.

Dans cet article, nous allons examiner plus en profondeur la structure de ces jetons, comment ils sont créés, échangés et utilisés, ainsi que les erreurs courantes liées à leur mise en œuvre.

Jeton d'identité : Le passeport numérique

L'ID token fonctionne comme une sorte de passeport numérique. Il est signé par une autorité de confiance, et peut être vérifié par n'importe quelle application qui accepte ce fournisseur d'identité. Ce jeton est conçu pour être lu par le client, c'est-à-dire l'application qui effectue la demande d'authentification. Il ne doit jamais être utilisé pour accéder à des ressources protégées. Ce qui est important ici, c'est que le jeton d'identité ne donne pas de droits d'accès. Il prouve seulement que vous êtes qui vous dites être.

Ce jeton est généralement au format JWT (JSON Web Token), qui est un standard ouvert pour créer des jetons portables. Le JWT contient trois parties : l'en-tête, la charge utile et la signature. L'en-tête spécifie le type de jeton (JWT) et l'algorithme de signature utilisé. La charge utile contient les informations sur l'utilisateur, souvent appelées "claims". Enfin, la signature permet de vérifier que le jeton n'a pas été altéré.

Un exemple simple de claims dans un jeton d'identité pourrait être :

• sub : l'identifiant de l'utilisateur
• name : le nom de l'utilisateur
• email : l'adresse e-mail de l'utilisateur
• iat : l'heure à laquelle le jeton a été émis
• exp : l'heure d'expiration du jeton

Ces informations permettent à l'application de connaître l'utilisateur, mais n'indiquent rien sur ses permissions d'accès aux ressources.

Jeton d'accès : Le ticket d'accès

Si le jeton d'identité est un passeport, alors le jeton d'accès est un ticket. Un ticket qui permet de faire certaines choses, mais pas toutes. Il ne fournit pas d'informations sur l'utilisateur au sens où le fait le jeton d'identité, mais plutôt sur ce que l'utilisateur est autorisé à faire.

Les jetons d'accès sont également souvent des JWT, bien que cela ne soit pas obligatoire. Ils incluent des informations sur les permissions accordées à l'utilisateur. Par exemple, un jeton d'accès pourrait indiquer que l'utilisateur peut lire ses e-mails, mais ne peut pas les modifier, ou qu'il peut accéder à son calendrier mais ne peut pas en ajouter d'événements.

Un jeton d'accès typique peut contenir les éléments suivants :

• scope : les actions autorisées, comme "read" ou "write"
• aud : le serveur auquel ce jeton est destiné
• exp : la date d'expiration

Un point crucial à retenir ici est que le jeton d'accès ne doit pas être utilisé pour authentifier l'utilisateur, seulement pour autoriser des actions. C'est une distinction essentielle car elle permet de séparer l'authentification (prouver l'identité) de l'autorisation (permettre l'accès).

Différentes utilisations, mêmes principes

L'une des grandes forces du protocole OAuth2 est qu'il permet cette séparation claire entre l'authentification et l'autorisation. En ayant deux jetons distincts, le système devient plus modulaire et plus sécurisé. Une application peut vérifier l'identité de l'utilisateur sans nécessairement lui accorder des droits d'accès aux ressources, et elle peut aussi vérifier ces droits sans connaître tous les détails personnels de l'utilisateur.

Cela signifie que même si vous compromettez un jeton d'accès, vous ne compromettez pas l'identité de l'utilisateur, et inversement, ce qui limite les risques en cas de fuite de données.

Pourquoi cela compte-t-il pour les développeurs ?

Pour les développeurs d'applications, comprendre cette distinction est essentiel. Utiliser un jeton d'identité pour accéder à des ressources est une erreur de sécurité courante, tout comme essayer d'utiliser un jeton d'accès pour prouver l'identité d'un utilisateur. Ces erreurs peuvent exposer les applications à des attaques de falsification ou de répudiation, où un utilisateur malveillant peut essayer d'accéder à des ressources qu'il ne devrait pas.

De plus, le respect des bonnes pratiques d'OAuth2 garantit que les utilisateurs ont un contrôle granulaire sur leurs données. En séparant les rôles des jetons, les utilisateurs peuvent, par exemple, choisir de partager leur identité avec une application sans lui donner accès à leurs e-mails ou à leur calendrier.

Erreurs courantes et meilleures pratiques

• Utiliser un jeton d'identité pour autoriser des actions : C'est l'erreur la plus répandue. Un jeton d'identité ne devrait jamais être utilisé pour accéder à des ressources.
• Ne pas vérifier la signature du jeton : Chaque jeton d'accès ou d'identité est signé. Ne pas vérifier cette signature expose l'application à des risques importants.
• Stocker les jetons de manière non sécurisée : Les jetons sont sensibles et doivent être stockés de manière sécurisée, généralement dans un stockage local sécurisé côté client.

En résumé, le jeton d'identité et le jeton d'accès sont deux outils puissants dans OAuth2, chacun ayant un rôle distinct et des usages spécifiques. Comprendre ces différences permet aux développeurs de créer des applications plus sécurisées et de garantir que les utilisateurs ont un contrôle total sur leurs données.