Travailler avec des jetons et Organizations

La plupart des jetons d’ID et des jetons d’accès renvoyés par Auth0 sont des jetons Web JSON (JWT) 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.

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.

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"
}

{
  "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"  
  ]
}

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.

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"
}

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.

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.

• Comprendre le fonctionnement des organisations Auth0
• Créez de votre première Organization
• Développement personnalisé avec les Organizations
• Configurer les Organizations