Passer au contenu principal
Il existe deux types de jetons liés à l’identité : les et les .

ID tokens

Les ID tokens 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 un ID token à l’application qui contient des informations sur l’utilisateur. L’application analyse ensuite le contenu du jeton et utilise ces informations (y compris des détails comme le nom et la photo de profil) pour personnaliser l’expérience utilisateur.
Assurez-vous de valider les ID tokens avant d’utiliser les informations qu’ils contiennent. Vous pouvez utiliser une bibliothèque pour vous aider dans cette tâche.
N’utilisez pas les ID tokens pour accéder à une API. Chaque jeton contient des informations sur l’ visée (qui est généralement le destinataire). Selon la spécification Connect, l’audience de l’ID token (indiquée par la revendication aud) doit être l’ de l’application qui effectue la demande d’authentification. Si ce n’est pas le cas, vous ne devriez pas faire confiance au jeton. Le contenu décodé d’un ID token ressemble à ce qui suit : Ce jeton sert à authentifier l’utilisateur auprès de l’application. L’audience (la revendication aud) du jeton correspond à l’identifiant de l’application, ce qui signifie que seule cette application devrait utiliser ce jeton. À l’inverse, une API s’attend à ce que la valeur aud d’un jeton corresponde à l’identifiant unique de l’API. Par conséquent, à moins que vous ne contrôliez à la fois l’application et l’API, l’envoi d’un jeton d’identité à une API ne fonctionnera généralement pas. Comme le ID Token n’est pas signé par l’API, celle-ci n’aurait aucun moyen de savoir si l’application avait modifié le jeton (p. ex., en y ajoutant des scopes) si elle acceptait le ID Token. 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 a été autorisé à y accéder et à effectuer un ensemble prédéfini d’actions (précisé par les scopes accordés). Dans l’exemple Google ci-dessus, Google envoie un jeton d’accès à l’application une fois que l’utilisateur s’est connecté et a donné son consentement pour que l’application lise ou modifie son Google Calendar. Chaque fois que l’application veut apporter des modifications à 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 déterminer si l’utilisateur s’est authentifié. La seule information sur l’utilisateur contenue dans le jeton d’accès est l’ID de l’utilisateur, situé dans la revendication 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 identifiant (revendication sub). Il contient uniquement des informations d’autorisation sur les actions que l’application est autorisée à effectuer dans l’API (revendication 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’inclure dans le jeton d’accès des renseignements supplémentaires sur l’utilisateur ou d’autres revendications personnalisées, en plus de la revendication sub, afin d’éviter à l’API d’avoir à faire un travail supplémentaire pour récupérer des détails sur l’utilisateur. Si vous choisissez de le faire, gardez à l’esprit que ces revendications supplémentaires seront lisibles dans le jeton d’accès. Pour en savoir plus, consultez Create 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 que l’utilisateur ait à se réauthentifier.
  • 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 appeler des API tierces.
  • Auth0 jetons d’accès: Jetons à courte durée de vie contenant des revendications précises (scopes) qui vous permettent d’appeler des points de terminaison de la Management API.

En savoir plus