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

​
Jetons d’ID

Les jetons d’ID sont des Jetons Web JSON (JWT) destinés à être utilisés uniquement par l’application. Par exemple, si une application utilise Google pour connecter les utilisateurs et synchroniser leurs calendriers, Google envoie à l’application un jeton d’ID contenant des informations sur l’utilisateur. L’application analyse ensuite le contenu du jeton et utilise les informations (y compris des détails tels que le nom et la photo de profil) pour personnaliser l’expérience de l’utilisateur.
Assurez-vous de valider les jetons d’ID avant d’utiliser les informations qu’ils contiennent. Vous pouvez utiliser une bibliothèque pour vous aider dans cette tâche.
N’utilisez pas de jetons d’ID pour accéder à une API. Chaque jeton contient des informations destinées à l’ visée (qui est généralement le destinataire). Selon la spécification  Connect, l’audiance du jeton d’ID (indiquée par la demande aud) doit être l’ID client de l’application qui fait la demande d’authentification. Si ce n’est pas le cas, vous ne devez pas faire confiance au jeton. Le contenu décodé d’un jeton d’ID ressemble à ce qui suit : 
{
  "iss": "http://{yourDomain}/",
  "sub": "auth0|123456",
  "aud": "{yourClientId}",
  "exp": 1311281970,
  "iat": 1311280970,
  "name": "Jane Doe",
  "given_name": "Jane",
  "family_name": "Doe",
  "gender": "female",
  "birthdate": "0000-10-31",
  "email": "janedoe@example.com",
  "picture": "http://example.com/janedoe/me.jpg"
}
Ce jeton authentifie l’utilisateur auprès de l’application. L’audience (la demande aud) du jeton est définie sur l’identifiant de l’application, ce qui signifie que seule cette application spécifique doit consommer ce jeton. Inversement, une API s’attend à ce qu’un jeton ayant la valeur aud 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’ID à une API ne fonctionnera généralement pas. Étant donné que le jeton d’ID n’est pas signé par l’API, cette dernière n’aurait aucun moyen de savoir si l’application a modifié le jeton (par exemple, en ajoutant d’autres permissions) si elle devait accepter le jeton d’ID. Voir le JWT Handbook (Manuel JWT) pour plus d’informations.

​
Les jetons d’accès

Les jetons d’accès (qui ne sont pas toujours des ) sont utilisés pour informer une API que le porteur du jeton a été autorisé à accéder à l’API et à effectuer un ensemble prédéterminé d’actions (spécifiées par les permissions accordées). Dans l’exemple de Google ci-dessus, Google envoie un jeton d’accès à l’application après que l’utilisateur s’est connecté et a donné son accord pour que l’application lise ou écrive dans son agenda Google. Lorsque l’application souhaite écrire dans Google Calendar, elle envoie une demande à l’API Google Calendar, en incluant le jeton d’accès dans l’en-tête HTTP Autorisation. 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 de l’utilisateur que possède le jeton d’accès est l’identifiant de l’utilisateur, situé dans la demande sub. Dans vos applications, traitez les jetons d’accès comme des chaînes opaques, car ils sont destinés aux API. Votre application ne doit pas tenter de décoder ni s’attendre à recevoir des jetons dans un format particulier. Voici un exemple de jeton d’accès : 
{
  "iss": "https://{yourDomain}/",
  "sub": "auth0|123456",
  "aud": [
    "my-api-identifier",
    "https://{yourDomain}/userinfo"
  ],
  "azp": "{yourClientId}",
  "exp": 1489179954,
  "iat": 1489143954,
  "scope": "openid profile email address phone read:appointments"
}
Notez que le jeton ne contient aucune information sur l’utilisateur en dehors de son ID (demande sub). Il ne contient que des informations d’autorisation sur les actions que l’application est autorisée à effectuer au niveau de l’API (demande 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 souhaitable de mettre des informations supplémentaires sur l’utilisateur ou d’autres demandes personnalisées, en plus de la sous-demande, dans le jeton d’accès pour é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 demandes supplémentaires seront lisibles dans le jeton d’accès. Pour en savoir plus, lisez Créer des demandes personnalisées.

​
Jetons spécialisés

Il existe trois jetons spécialisés utilisés dans les scénarios d’authentification par jeton d’Auth0 :
  • Jetons d’actualisation : jeton utilisé pour obtenir un jeton d’accès actualisé sans avoir à réauthentifier l’utilisateur.
  • Jetons d’accès des  : jetons d’accès délivrés par les fournisseurs d’identité après l’authentification de l’utilisateur, que vous pouvez utiliser pour appeler les API tierces.
  • Jetons d’accès à l’Auth0 Management API : jetons de courte durée contenant des demandes spécifiques (permissions) qui vous permettent d’appeler les points de terminaison de .

​
En savoir plus

⌘I