Passer au contenu principal
En tant que développeur d’API, vous devez :
  1. Déterminer à quelles informations vous voulez permettre aux applications d’accéder pour le compte d’un utilisateur.
  2. Définir ces niveaux d’accès comme des scopes personnalisés. (Pour savoir ce que sont les scopes, consultez Scopes.)
  3. Identifier ces scopes afin que les applications appelantes puissent les utiliser.

​
Façons d’utiliser les scopes d’API

Vous pouvez utiliser les scopes d’API de différentes manières :
  • 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 refusera 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 le configurer pour qu’il soit requis.
  • Dans une API où l’application appelante est un service back-end, qu’il soit tiers ou de première partie, et où aucun utilisateur n’existe. 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 aussi utiliser 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 un accès personnalisé à l’API pour votre application, consultez Exemples de cas d’utilisation : scopes et revendications.

​
Exemple : une API appelée par une application tierce

Supposons que vous concevez une API qui fournit des renseignements sur les comptes bancaires à des applications de paiement en ligne. Selon les besoins, les applications peuvent devoir consulter les soldes des comptes ou transférer des fonds. Pour ce faire, vous créez deux scopes pour votre API : l’un autorise l’accès en lecture au solde d’un compte (read:balance), l’autre autorise les transferts de fonds (transfer:funds). Votre API est enregistrée dans Auth0. Une application appelante demandera à l’utilisateur l’autorisation d’accéder aux scopes demandés, et l’utilisateur approuvera ou refusera la demande. L’application peut demander un accès en lecture au solde de l’utilisateur en incluant le scope read:balance dans sa demande, l’accès nécessaire pour effectuer des transferts de fonds en incluant le scope transfer:funds dans sa demande, ou l’accès permettant à la fois de consulter le solde de l’utilisateur et de transférer des fonds en incluant les scopes read:balance et transfer:funds dans sa demande. Lorsque l’application appelle votre API, elle inclut alors un jeton qui confirme que l’utilisateur a autorisé l’accès à son contenu et indique également quels scopes l’utilisateur a approuvés. Votre API doit respecter les scopes approuvés et ne transmettre à l’application appelante que les renseignements autorisés par l’utilisateur.

​
Exemple : une API appelée par une application de première partie

Supposons que vous développiez une API qui fournit des données à une application de gestion d’événements que vous avez également développée. Vous mettez en œuvre le contrôle d’accès basé sur les rôles (RBAC) en créant un rôle organizer et un rôle participant. Les utilisateurs ayant le rôle organizer doivent pouvoir créer et mettre à jour des événements, tandis que les utilisateurs ayant le rôle participant doivent pouvoir consulter des événements et s’y inscrire. Pour ce faire, vous créez quatre scopes pour votre API : un qui autorise la création d’événements (create:events), un qui autorise la mise à jour d’événements (update:events), un qui autorise l’accès en lecture seule aux événements (view:events) et un 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 Allow Skipping User Consent 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éé les scopes create:events et update:events pour ce rôle, puis attribué ce rôle à l’utilisateur A. Vous avez également configuré un rôle participant, créé les scopes view:events et register:events pour ce rôle, puis attribué ce rôle à 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 n’est pas requis. 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. Désormais, 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é.

​
Exemple : une API appelée par un service back-end

Supposons que vous travaillez pour un hôpital et que vous disposez d’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 doit conserver les images à long terme afin de respecter les exigences réglementaires. Pour cette raison, l’hôpital utilise 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 leur suppression (delete:images). Votre API et le service automatisé sont enregistrés dans 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 aucun utilisateur n’est impliqué, aucun consentement ne sera demandé. Le service peut demander un accès en lecture à vos données d’imagerie en incluant le scope read:images dans sa demande, un accès en suppression en incluant le scope delete:images dans sa demande, ou à la fois l’accès en lecture et l’accès en suppression en incluant les scopes read:images et delete:images dans sa demande. Désormais, lorsque le service automatisé appelle votre API, il inclut un jeton qui confirme qu’il est autorisé à utiliser les scopes demandés.

​
Limiter les scopes d’API

Une application peut inclure n’importe quel scope défini pour une API dans sa requête. Toutefois, plutôt que 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.

​
En savoir plus