> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Définir et utiliser des scopes personnalisés sur votre API Auth0 pour mettre en œuvre le contrôle d’accès et appliquer les permissions dans votre application.

# scopes d’API

En tant que développeur d’API, vous devez :

1. Déterminer à quelles informations vous voulez que les applications puissent accéder au nom d’un utilisateur.
2. Définir ces niveaux d’accès comme des scopes personnalisés. (Pour en savoir plus sur les scopes, consultez [Scopes](/docs/fr-ca/get-started/apis/scopes).)
3. Identifier ces scopes afin que les applications appelantes puissent les utiliser.

<div id="ways-to-use-api-scopes">
  ## Façons d’utiliser les scopes d’API
</div>

Vous pouvez utiliser les scopes d’API de différentes façons :

* Dans une API où l’application appelante est une application tierce ou externe. Dans ce cas, l’application appelante demandera à l’utilisateur l’autorisation d’accéder aux scopes demandés, et l’utilisateur approuvera ou rejettera la demande.
* Dans une API où l’application appelante est une application de première partie, c’est-à-dire une application enregistrée sous le même domaine Auth0 que l’API qu’elle appelle. Dans ce cas, par défaut, le consentement de l’utilisateur n’est pas demandé, mais vous pouvez configurer le consentement pour qu’il soit obligatoire.
* Dans une API où l’application appelante est un service back-end, qu’il soit tiers ou de première partie, et où il n’y a pas d’utilisateur. Dans ce cas, le consentement de l’utilisateur n’est jamais demandé.

Tous ces exemples utilisent des scopes pour limiter l’accès au moyen d’un jeton. Si vous le souhaitez, votre API peut également s’appuyer sur une logique supplémentaire, au-delà du jeton, pour appliquer un contrôle d’accès plus étendu.

Pour voir un exemple montrant comment demander l’accès à une API personnalisée pour votre application, consultez [Exemples de cas d’utilisation : Scopes and Claims](/docs/fr-ca/get-started/apis/scopes/sample-use-cases-scopes-and-claims).

<div id="example-an-api-called-by-a-third-party-application">
  ### Exemple : une API appelée par une application tierce
</div>

Supposons que vous développez une API qui fournit des renseignements sur des comptes bancaires à des applications de paiement en ligne. À différents moments, les apps peuvent avoir besoin de consulter le solde des comptes ou de transférer des fonds. Pour ce faire, vous créez deux scopes pour votre API : un qui autorise l’accès en lecture au solde d’un compte (`read:balance`) et un autre qui autorise les transferts de fonds (`transfer:funds`). Votre API est enregistrée auprès d’Auth0.

Une application appelante demandera à l’utilisateur l’autorisation d’accéder aux scopes demandés, et l’utilisateur approuvera ou rejettera la requête. L’app peut demander un accès en lecture au solde de l’utilisateur en incluant le scope `read:balance` dans sa requête, un accès pour effectuer des transferts de fonds en incluant le scope `transfer:funds` dans sa requête, ou l’accès à la fois pour lire le solde de l’utilisateur et transférer des fonds en incluant les scopes `read:balance` et `transfer:funds` dans sa requête.

Ensuite, lorsque l’app fera une requête à votre API, elle inclura un jeton qui confirme que l’utilisateur a donné l’autorisation d’accéder à son contenu et qui indique aussi quels scopes l’utilisateur a approuvés. Votre API doit respecter les scopes approuvés et ne transmettre à l’application appelante que les renseignements que l’utilisateur a autorisés.

<div id="example-an-api-called-by-a-first-party-application">
  ### Exemple : une API appelée par une application de première partie
</div>

Supposons que vous créez une API qui fournit des données à une application de gestion d’événements que vous avez également développée. Vous [implémentez le contrôle d’accès basé sur les rôles (RBAC)](/docs/fr-ca/manage-users/access-control/rbac), en créant un rôle `organizer` et un rôle `participant`. Les utilisateurs ayant le rôle `organizer` doivent créer et mettre à jour des événements, tandis que les utilisateurs ayant le rôle `participant` doivent consulter les événements et s’y inscrire. Pour ce faire, vous créez quatre scopes pour votre API : une qui autorise la création d’événements (`create:events`), une qui autorise la mise à jour d’événements (`update:events`), une qui autorise l’accès en lecture seule aux événements (`view:events`) et une qui autorise l’inscription aux événements (`register:events`). Votre API et votre application d’événements sont toutes deux enregistrées dans Auth0, et l’option **Autoriser l’omission du consentement de l’utilisateur** pour les applications de première partie est activée pour votre API. Vous avez installé l’Authorization Extension, configuré un rôle `organizer`, créé pour celui-ci les scopes `create:events` et `update:events`, puis l’avez attribué à l’utilisateur A. Vous avez également configuré un rôle `participant`, créé pour celui-ci les scopes `view:events` et `register:events`, puis l’avez attribué à l’utilisateur B.

L’utilisateur A s’authentifie auprès de l’application appelante, qui demande les scopes nécessaires, mais comme il s’agit d’une application de première partie, le consentement de l’utilisateur ne lui sera pas demandé. L’application peut demander n’importe quelle combinaison des scopes `create:events`, `update:events`, `view:events` et `register:events`, mais l’utilisateur A est reconnu comme ayant le rôle `organizer` et, par conséquent, seuls les scopes `create:events` et `update:events` lui sont accordés.

Lorsque l’application appelle votre API, elle inclut un jeton qui confirme qu’elle n’est autorisée qu’aux scopes associés au rôle de l’utilisateur authentifié.

<div id="example-an-api-called-by-a-back-end-service">
  ### Exemple : une API appelée par un service back-end
</div>

Supposons que vous travaillez pour un hôpital et que vous avez une API qui produit de grandes quantités de données d’imagerie chaque fois qu’un patient passe une IRM. Vous stockez les données d’imagerie localement pendant six mois, mais l’hôpital a besoin que les images soient conservées à long terme à des fins de conformité réglementaire. Pour cette raison, l’hôpital dispose d’un service qui copie chaque nuit les données d’imagerie vers une solution de stockage à froid hors site et supprime toutes les données médicales locales après six mois de conservation.

Pour ce faire, vous créez deux scopes pour votre API : un qui autorise l’accès en lecture à vos données d’imagerie (`read:images`) et un qui autorise l’accès de suppression à vos données d’imagerie (`delete:images`). Votre API et le service automatisé sont enregistrés auprès d’Auth0, et vous avez autorisé le service automatisé à demander des jetons pour votre API.

Le service automatisé qui appelle l’API demandera les scopes nécessaires, mais comme il n’y a pas d’utilisateur, le consentement ne sera pas demandé. Le service peut demander un accès en lecture à vos données d’imagerie en incluant le scope `read:images` dans sa requête, un accès de suppression en incluant le scope `delete:images` dans sa requête, ou à la fois un accès en lecture et de suppression en incluant les scopes `read:images` et `delete:images` dans sa requête.

Désormais, lorsque le service automatisé appelle votre API, il inclura un jeton attestant qu’il est autorisé pour les scopes demandés.

<div id="limit-api-scopes">
  ## Limiter les scopes d’API
</div>

Une application peut inclure n’importe quel scope défini pour une API dans sa requête. Toutefois, au lieu d’autoriser la demande de tous les scopes disponibles, vous pouvez contrôler la façon dont les applications accèdent à vos API à l’aide des [politiques d’accès aux API pour les applications](/docs/fr-ca/get-started/apis/api-access-policies-for-applications).

<div id="learn-more">
  ## En savoir plus
</div>

* [Exemples de cas d’utilisation : Scopes et Claims](/docs/fr-ca/get-started/apis/scopes/sample-use-cases-scopes-and-claims)
* [Ajouter des permissions d’API](/docs/fr-ca/get-started/apis/add-api-permissions)
* [Personnaliser les écrans de consentement](/docs/fr-ca/customize/login-pages/customize-consent-prompts)
* [Configurer une API logique pour plusieurs API](/docs/fr-ca/get-started/apis/set-logical-api)
* [Obtenir des jetons d’accès à la Management API pour la production](/docs/fr-ca/secure/tokens/access-tokens/management-api-access-tokens/get-management-api-access-tokens-for-production)
* [Obtenir des jetons d’accès à la Management API pour les tests](/docs/fr-ca/secure/tokens/access-tokens/management-api-access-tokens/get-management-api-access-tokens-for-testing)