Passer au contenu principal

La disponibilité varie selon le forfait Auth0

Votre forfait Auth0 ou votre entente personnalisée détermine si cette fonctionnalité est offerte. Pour en savoir plus, consultez Tarification.
La plupart des jetons d’identité (ID) et des renvoyés par Auth0 sont des (JWT) qui contiennent diverses claims, c’est-à-dire des éléments d’information déclarés au sujet d’un sujet. Par exemple, un jeton d’identité (qui est toujours un JWT) peut contenir une claim appelée name qui indique que le nom de l’utilisateur qui s’authentifie est « John Doe ». Il existe deux types de claims dans un JWT :
  • Enregistrées : claims définies par la spécification JWT pour assurer l’interopérabilité avec des applications tierces ou externes. Les claims standard OpenID Connect (OIDC) sont des claims réservées.
  • Personnalisées : claims que vous définissez vous-même. Ces claims peuvent être des claims publiques non enregistrées et résistantes aux collisions, ou des claims privées non enregistrées, non publiques et sujettes aux collisions. Nommez ces claims avec soin, par exemple au moyen d’un espace de noms, afin d’éviter les collisions avec des claims réservées ou d’autres claims personnalisées. Il peut être difficile de gérer deux claims portant le même nom qui contiennent des informations différentes.
Pour en savoir plus sur les claims, consultez Claims des JSON Web Tokens.

​
Authentifier les utilisateurs via une organisation

Pour authentifier un utilisateur via une organisation, ajoutez un paramètre organization à un appel au point de terminaison /authorize. Des exemples de jetons renvoyés lorsqu’un utilisateur se connecte via une organisation sont fournis ci-dessous.
Par défaut, les jetons d’identité et d’accès incluent uniquement les ID d’organisation. Cependant, vous pouvez configurer votre locataire pour autoriser l’utilisation de noms d’organisation dans l’Authentication API. Une fois cette option configurée, les jetons d’identité et d’accès contiennent à la fois les claims org_id et org_name. Pour en savoir plus, consultez Utiliser des noms d’organisation dans l’Authentication API.

​
Jeton d’identité

Dans l’exemple suivant, notez que https://marketplace/roles et https://namespace.exampleco.com/ sont des claims personnalisés ajoutés au jeton, tandis que les autres claims inclus 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 machine à machine à une organisation

Dans les cas d’utilisation machine à machine, un paramètre organization est ajouté à la requête Client Credentials envoyée 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 ID et les jetons d’accès incluent uniquement les ID d’organisation. Cependant, vous pouvez configurer votre locataire pour autoriser l’utilisation des noms d’organisation dans l’Authentication API. Une fois cette option configurée, les jetons ID et les jetons d’accès contiennent à la fois les claims org_id et org_name. Pour en savoir plus, consultez Utiliser les noms d’organisation dans l’Authentication API.
L’exemple de code suivant présente un jeton d’accès renvoyé dans les cas d’utilisation machine à machine : 
{
  "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 vers le point de terminaison /authorize ou le point de terminaison /oauth/token, les SDK Auth0 valident automatiquement la claim org_id, renvoyée dans tous les jetons générés. Toutefois, pour des raisons de sécurité, une validation supplémentaire doit être effectuée à la réception des jetons.
Si vous avez configuré votre locataire pour autoriser l’utilisation de noms d’organisation dans l’Authentication API, les jetons d’identité et les jetons d’accès contiennent à la fois les claims org_id et org_name. Si cette claim est présente, validez org_name en plus de org_id pour vous assurer que les valeurs reçues correspondent à une entité de confiance.En général, l’utilisation des identifiants d’organisation est la méthode privilégiée pour valider les jetons. Toutefois, les noms d’organisation peuvent être utilisés s’ils conviennent mieux à votre cas d’utilisation. Pour comprendre les implications possibles de l’utilisation de noms d’organisation pour valider les jetons, consultez Use Organization Names in Authentication API.
Pour les applications Web : Si aucun paramètre organization n’a été transmis au point de terminaison /authorize, mais qu’une claim org_id est présente dans le , votre application doit valider la claim afin de s’assurer que la valeur reçue est attendue ou connue et qu’elle correspond à une entité à laquelle votre application fait confiance, comme un client payant. Si la claim ne peut pas être validée, l’application doit considérer le jeton comme invalide. Pour les API : Si une claim org_id est présente dans le jeton d’accès, votre API doit valider la claim afin de s’assurer que la valeur reçue est attendue ou connue et qu’elle correspond à une entité à laquelle votre application fait confiance, comme un client payant. Si la claim ne peut pas être validée, l’API doit considérer le jeton comme invalide. En particulier :
  • La claim iss (émetteur) doit être vérifiée pour s’assurer que le jeton a été émis par Auth0.
  • La claim org_id doit être vérifiée pour s’assurer qu’il s’agit d’une valeur déjà connue de l’application. Cette valeur peut être validée par rapport à une liste connue d’identifiants d’organisation, ou vérifiée conjointement avec l’URL de la requête en cours. Par exemple, le sous-domaine peut indiquer quelle organisation doit être utilisée lors de la validation de l’ID Token.
Normalement, la validation du seul émetteur suffirait à confirmer que le jeton a été émis par Auth0. Dans le cas des organisations, toutefois, des vérifications supplémentaires doivent être effectuées pour s’assurer que l’organisation au sein de votre locataire Auth0 est bien celle attendue. Il est également très important que vos serveurs d’API segmentent l’accès aux données et aux ressources en fonction de org_id. Cela garantit que seules les informations d’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