Passer au contenu principal

La disponibilité varie selon le plan Auth0

Votre plan Auth0 ou votre accord personnalisé ont un impact sur la disponibilité de cette fonctionnalité. Pour en savoir plus, lisez Tarification.
La plupart des jetons d’ID et des jetons d’accès renvoyés par Auth0 sont des jetons Web JSON () contenant une variété d’autorisations, qui sont des éléments d’information concernant un sujet. Par exemple, un jeton d’ID (qui est toujours un JWT) peut contenir une demande appelée name qui affirme que le nom de l’utilisateur qui s’authentifie est «Pierre Untel». Il existe deux types de demandes JWT :
  • Enregistrée : Demandes définies par la spécification JWT pour assurer l’interopérabilité avec les applications tierces ou externes. Les demandes standard OpenID Connect (OIDC) sont des demandes réservées.
  • Personnalisée : Demandes que vous définissez vous-même. Il peut s’agir d’autorisations publiques non enregistrées et résistantes aux collisions ou d’autorisations privées non enregistrées et non publiques sujettes aux collisions. Nommez ces demandes avec soin, par exemple au moyen de l’espace de nommage, afin d’éviter toute collision avec des demandes réservées ou d’autres demandes personnalisées. Il peut être difficile de traiter deux demandes d’autorisation portant le même nom et contenant des informations différentes.
Pour en savoir plus sur les demandes, consultez Demandes de jetons Web JSON.

​
Authentifier les utilisateurs par l’intermédiaire d’une organization

Pour authentifier un utilisateur par l’intermédiaire d’une organization, un paramètre organization est ajouté à un appel au point de terminaison /authorize. Des exemples de jetons renvoyés lorsqu’un utilisateur se connecte par l’intermédiaire d’une organization sont présentés ci-dessous.
Par défaut, les jetons d’accessibilité et d’ID n’incluent que des ID d’organisation. Cependant, vous pouvez configurer votre locataire pour permettre l’utilisation de noms d’organisation dans la Authentication API. Lorsqu’ils sont configurés, les jetons d’accès et d’ID contiennent tous deux les demandes org_id et org_name. Pour en savoir plus, consultez Utiliser des noms d’organisation dans la Authentication API.

​
Jeton d’ID

Dans l’exemple suivant, notez que https://marketplace/roles et https://namespace.exampleco.com/ sont des demandes personnalisées qui ont été ajoutées au jeton, tandis que les autres demandes incluses sont standard. 
{
  "https://marketplace/roles": [
    "marketplace-administrator"
  ],
  "https://namespace.exampleco.com": "my custom claim",
  "nickname": "firstName.lastName",
  "name": "firstName.lastName@email.com",
  "picture": "https://s.gravatar.com/avatar/638",
  "updated_at": "2021-03-23T11:34:14.566z",
  "email": "username@exampleco.com",
  "email_verified": true,
  "sub": "auth0|602c0dcab993d10073daf680",
  "org_id": "org_9ybsU1dN2dKfDkBi"
}

​
Jeton d’accès

{
  "iss": "https://exampleco.auth0.com/",
  "sub": "auth0|602c0dcab993d10073daf680",
  "aud": [
    "https://example-api/",
    "https://exampleco.auth0.com/userinfo"  
  ],
  "iat": 1616499255,
  "exp": 1616585655,
  "azp": "ENDmmAJsbwI1hOG1KPJddQ8LHjV6kLkV",
  "scope": "openid profile email",
  "org_id": "org_9ybsU1dN2dKfDkBi",
  "permissions": [
    "delete:stuff",
    "read:stuff",
    "write:stuff"  
  ]
}

​
Accès de communication entre machines à une organisation

Dans les cas de communication entre machines, un paramètre organization est ajouté à la demande Client Credentials au point de terminaison /oauth/token afin qu’une application puisse obtenir un jeton d’accès pour elle-même plutôt que pour un utilisateur.
Par défaut, les jetons d’accessibilité et d’ID n’incluent que des ID d’organisation. Cependant, vous pouvez configurer votre locataire pour permettre l’utilisation de noms d’organisation dans la Authentication API. Lorsqu’ils sont configurés, les jetons d’accès et d’ID contiennent tous deux les demandes org_id et org_name. Pour en savoir plus, consultez Utiliser les noms d’Organisation dans Authentication API.
L’exemple de code suivant est un exemple de jeton d’accès renvoyé dans les cas d’une communication entre machines. 
{
  "iss": "https://exampleco.auth0.com/",
  "sub": "CS2MNgcX1VZFCJaEzfKw2VPAAS0gzhqP@clients",
  "aud": "https://example-api",
  "iat": 1727782196,
  "exp": 1727868596,
  "scope": "scope1 scope2",
  "org_id": "org_vIK75NKFvaozQsFy",
  "org_name": "acme",
  "gty": "client-credentials",
  "azp": "CS2MNgcX1VZFCJaEzfKw2VPAAS0gzhqP"
}

​
Valider les jetons

Lorsque le paramètre organization est ajouté à un appel au point de terminaison /authorize ou au point de terminaison /oauth/token, les trousses SDK Auth0 valident automatiquement la demande org_id, qui est renvoyée dans le cadre de tout jeton généré. Toutefois, à des fins de sécurité, une validation supplémentaire doit être effectuée lors de la réception des jetons.
Si vous avez configuré votre locataire pour permettre l’utilisation de noms d’organisation dans la Authentication API, les jetons d’accès et d’ID contiennent tous les deux les demandes org_id et org_name. S’il existe, validez la demande org_name et org_id pour vous assurer que les valeurs reçues correspondent à une entité de confiance.En général, utiliser des ID d’organisation est une méthode préférable pour la validation des jetons. Cependant, les noms d’organisation peuvent être utilisés s’ils sont plus appropriés pour le cas d’utilisation. Pour comprendre les implications potentielles d’utiliser des noms d’organisation pour valider des jetons, consultez Utiliser des noms d’organisation dans la Authentication API.
Pour les applications web : Si aucun paramètre organization n’a été transmis au point de terminaison /authorize, mais qu’une demande org_id est présente dans le jeton d’ID, votre application doit valider la demande pour s’assurer que la valeur reçue est attendue ou connue et qu’elle correspond à une entité en laquelle votre application a confiance, telle qu’un client payant. Si la demande ne peut être validée, l’application doit considérer le jeton comme non valide. Pour les API : Si une demande org_id est présente dans le jeton d’accès, votre API doit valider la demande pour s’assurer que la valeur reçue est attendue ou connue et qu’elle correspond à une entité en laquelle votre application a confiance, telle qu’un client payant. Si la demande ne peut pas être validée, l’API doit considérer le jeton comme non valide. En particulier :
  • La demande iss (émetteur) doit être vérifiée pour s’assurer que le jeton a été émis par Auth0.
  • L’affirmation org_id doit être vérifiée pour s’assurer qu’il s’agit d’une valeur déjà connue de l’application. Elle pourrait être validée par rapport à une liste connue d’identifiants d’organizations, ou être vérifiée en conjonction avec l’URL de la demande actuelle. Par exemple, le sous-domaine peut indiquer l’organization à utiliser lors de la validation du jeton d’ID.
Normalement, il suffirait de valider l’émetteur pour s’assurer que le jeton a été émis par Auth0. Dans le cas des organizations, cependant, des vérifications supplémentaires doivent être effectuées pour s’assurer que l’organization au sein de votre locataire Auth0 est conforme aux attentes. Il est également très important que vos serveurs API segmentent l’accès aux données et aux ressources en fonction de la valeur org_id. Cela garantit que seules les informations relatives à une organisation donnée peuvent être consultées ou modifiées lorsque la valeur org_id correspondant à cette organisation est reçue dans le jeton d’accès.

​
En savoir plus

⌘I