> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-eval-flywheel-swift-quickstart.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Travailler avec des jetons et Organizations

> Découvrez comment les jetons fonctionnent avec la fonctionnalité Organizations d’Auth0 et comment authentifier les utilisateurs appartenant à une organization.

<Card title="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](https://auth0.com/pricing).
</Card>

La plupart des jetons d’ID et des jetons d’accès renvoyés par Auth0 sont des jetons Web JSON (<Tooltip href="/docs/fr-ca/glossary?term=json-web-token" tip="Jeton Web JSON (JWT)
Format standard de jeton d’ID (et souvent de jeton d’accès) utilisé pour représenter en toute sécurité des demandes entre deux parties." cta="Voir le glossaire">JWT</Tooltip>) contenant une variété d’autorisations, qui sont des éléments d’information concernant un sujet. Par exemple, un [jeton d’ID](/docs/fr-ca/secure/tokens/id-tokens) (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](https://tools.ietf.org/html/rfc7519) pour assurer l’interopérabilité avec les applications tierces ou externes. Les demandes standard [OpenID Connect (OIDC)](/docs/fr-ca/authenticate/protocols/openid-connect-protocol) 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](/docs/fr-ca/secure/tokens/json-web-tokens/create-custom-claims), 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](/docs/fr-ca/secure/tokens/json-web-tokens/json-web-token-claims).

## 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.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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](/docs/fr-ca/manage-users/organizations/configure-organizations/use-org-name-authentication-api).
</Callout>

### 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.

```json lines theme={null}
{
  "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

```json lines theme={null}
{
  "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.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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](/docs/fr-ca/manage-users/organizations/configure-organizations/use-org-name-authentication-api).
</Callout>

L’exemple de code suivant est un exemple de jeton d’accès renvoyé dans les cas d’une communication entre machines.

```json lines theme={null}
{
  "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.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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](/docs/fr-ca/manage-users/organizations/configure-organizations/use-org-name-authentication-api).
</Callout>

**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

* [Comprendre le fonctionnement des organisations Auth0](/docs/fr-ca/manage-users/organizations/organizations-overview)
* [Créez de votre première Organization](/docs/fr-ca/manage-users/organizations/create-first-organization)
* [Développement personnalisé avec les Organizations](/docs/fr-ca/manage-users/organizations/custom-development)
* [Configurer les Organizations](/docs/fr-ca/manage-users/organizations/configure-organizations)
