Skip to main content
Il existe deux types de jetons liés à l’identité : et .

​
Jetons d’ID

Les jetons d’ID sont des JSON Web Tokens (JWTs) destinés à être utilisés uniquement par l’application. Par exemple, si une application utilise Google pour permettre aux utilisateurs de se connecter et synchroniser leurs calendriers, Google envoie à l’application un jeton d’ID qui contient des renseignements sur l’utilisateur. L’application analyse ensuite le contenu du jeton et utilise ces renseignements (y compris des détails comme le nom et la photo de profil) pour personnaliser l’expérience utilisateur.
Assurez-vous de valider les jetons d’ID avant d’utiliser les renseignements qu’ils contiennent. Vous pouvez utiliser une bibliothèque pour vous aider dans cette tâche.
N’utilisez pas les jetons d’ID pour accéder à une API. Chaque jeton contient des renseignements sur l’ visée (qui est habituellement le destinataire). Selon la spécification Connect, l’audience du jeton d’ID (indiquée par le claim aud) doit être l’ de l’application qui effectue la requête d’authentification. Si ce n’est pas le cas, vous ne devriez pas vous fier à ce jeton. Le contenu décodé d’un jeton d’ID ressemble à ceci : Ce token authentifie l’utilisateur auprès de l’application. L’audience (la claim aud) du token correspond à l’identifiant de l’application, ce qui signifie que seule cette application doit utiliser ce token. À l’inverse, une API s’attend à recevoir un token dont la valeur aud correspond à l’identifiant unique de l’API. Par conséquent, à moins que vous n’ayez le contrôle à la fois de l’application et de l’API, l’envoi d’un jeton d’ID à une API ne fonctionnera généralement pas. Comme le jeton d’ID n’est pas signé par l’API, celle-ci n’aurait aucun moyen de savoir si l’application avait modifié le token (par exemple, en ajoutant des scopes supplémentaires) si elle acceptait le jeton d’ID. Consultez le JWT Handbook pour en savoir plus.

​
Jetons d’accès

Les jetons d’accès (qui ne sont pas toujours des ) servent à indiquer à une API que le porteur du jeton est autorisé à accéder à l’API et à effectuer un ensemble prédéterminé d’actions (défini par les portées accordées). Dans l’exemple Google ci-dessus, Google envoie un jeton d’accès à l’application une fois que l’utilisateur a ouvert une session et a donné son consentement pour que l’application puisse lire ou écrire dans son Google Calendar. Chaque fois que l’application veut écrire dans Google Calendar, elle envoie une requête à l’API Google Calendar en incluant le jeton d’accès dans l’en-tête HTTP Authorization. Les jetons d’accès ne doivent jamais être utilisés pour l’authentification. Les jetons d’accès ne permettent pas de savoir si l’utilisateur s’est authentifié. La seule information sur l’utilisateur que contient le jeton d’accès est l’ID utilisateur, situé dans le claim sub. Dans vos applications, traitez les jetons d’accès comme des chaînes opaques puisqu’ils sont destinés aux API. Votre application ne devrait pas tenter de les décoder ni s’attendre à recevoir des jetons dans un format particulier. Voici un exemple de jeton d’accès : Notez que le jeton ne contient aucune information sur l’utilisateur, à part son ID (claim sub). Il contient uniquement des renseignements d’autorisation sur les actions que l’application est autorisée à effectuer dans l’API (claim scope). C’est ce qui le rend utile pour sécuriser une API, mais pas pour authentifier un utilisateur. Dans certaines situations, il peut être utile d’ajouter au jeton d’accès des renseignements supplémentaires sur l’utilisateur ou d’autres custom claims, en plus du claim sub, afin d’éviter à l’API d’avoir à faire du travail supplémentaire pour récupérer des détails sur l’utilisateur. Si vous choisissez de le faire, gardez à l’esprit que ces claims supplémentaires seront lisibles dans le jeton d’accès. Pour en savoir plus, consultez Créer des custom claims.

​
Jetons spécialisés

Il existe trois jetons spécialisés utilisés dans les scénarios d’authentification par jeton d’Auth0 :
  •  : Jeton utilisé pour obtenir un nouveau jeton d’accès sans avoir à réauthentifier l’utilisateur.
  • jetons d’accès : Jetons d’accès émis par des fournisseurs d’identité après l’authentification de l’utilisateur, que vous pouvez utiliser pour faire des requêtes aux API tierces.
  • Jetons d’accès de la d’Auth0 : Jetons de courte durée contenant des claims précis (scopes) qui vous permettent de faire des requêtes aux points de terminaison de la Management API.

​
En savoir plus