Skip to main content
Si vous avez plusieurs mises en œuvre d’API distinctes qui font toutes logiquement partie de la même API, vous pouvez simplifier votre processus d’autorisation en les représentant par une seule API logique dans le . Vous pouvez ainsi mettre en place un seul , tout en continuant à contrôler l’accès à chaque API en attribuant les scopes appropriés. Les sections suivantes expliquent comment utiliser et représenter plusieurs API comme un seul dans Auth0. Nous utiliserons l’application d’exemple suivante. Cette application repose sur une architecture de microservices et comprend :
  • 2 API Node.js : contacts et calendar (vous pouvez les considérer comme des microservices)
  • 1 Resource Server représentant les 2 API
  • 2 scopes qualifiés par espace de noms : read:contacts et read:calendar
  • Le flux Implicit Grant pour obtenir un access_token qui fonctionne pour les deux API
Nous représenterons les deux API à l’aide d’une seule API Auth0 appelée Organizer Service. Nous créerons ensuite deux scopes pour montrer comment utiliser le flux implicite afin d’accéder aux API calendar et contacts à partir de la SPA. Vous devez effectuer les étapes suivantes :
  1. Activer une connexion pour votre application
  2. Créer un utilisateur de test
  3. Enregistrer une API logique dans Auth0
  4. Configurer des scopes pour l’API logique
  5. Accorder l’accès à l’API logique
  6. (Facultatif) Mettre en œuvre la déconnexion unique (SLO) ou l’authentification unique (SSO)

Prérequis

Activer une connexion pour votre application

Vous aurez besoin d’une source d’utilisateurs pour l’application que vous venez d’enregistrer; vous devrez donc configurer une connexion. Pour cet exemple, nous créerons une Connexion à une base de données simple qui demande seulement l’adresse courriel de l’utilisateur et un mot de passe. Pour en savoir plus, consultez Configurer les connexions à une base de données.

Créer un utilisateur de test

Comme vous travaillez avec une connexion nouvellement créée, aucun utilisateur n’y est associé. Avant de pouvoir tester le processus de connexion de l’application d’exemple, vous devrez créer un utilisateur et l’associer à la connexion. Assurez-vous donc de sélectionner votre nouvelle connexion lorsque vous créez votre utilisateur. Pour en savoir plus, consultez Créer des utilisateurs.

Enregistrer une API logique dans Auth0

Enregistrez une seule API logique que vous utiliserez pour représenter les multiples API contenues dans l’application d’exemple. Pour les besoins de cet exemple, nommez votre API Organizer Service et définissez son identifiant unique sur organize. Par défaut, l’ des jetons obtenus pour cette API est RS256, que vous devriez laisser tel quel. Pour en savoir plus, consultez Enregistrer des API.

Configurer les permissions pour l’API logique

Pour permettre à l’API logique de représenter les API comprises dans l’application exemple, vous devrez créer les permissions appropriées (scopes). Les scopes vous permettent de définir les actions d’API auxquelles les applications appelantes auront accès. Chaque scope représente une combinaison API/action. Dans cet exemple, vous voulez que les applications appelantes puissent read à partir d’une API nommée calendar et d’une autre nommée contacts; vous devrez donc créer les permissions suivantes :
  • read:calendar
  • read:contacts
Vous pouvez considérer chacune d’elles comme un microservice. Pour en savoir plus, consultez Ajouter des permissions d’API et Portées d’API.

Accorder l’accès à l’API logique

Vous êtes maintenant prêt à donner accès à vos API en permettant à l’API logique d’obtenir des . En incluant les scopes nécessaires, vous pouvez contrôler l’accès d’une application aux API représentées par l’API logique. Les étapes suivantes utilisent le flux implicite pour illustrer l’exemple. Toutefois, vous pouvez utiliser le flux qui convient le mieux à vos besoins. Par exemple : Pour en savoir plus sur les flux d’autorisation, consultez Flux d’authentification et d’autorisation.
  1. L’utilisateur clique sur Login dans la SPA, puis l’application redirige l’utilisateur vers l’Auth0 Authorization Server (point de terminaison /authorize). Pour en savoir plus sur les paramètres de la requête, consultez notre tutoriel : Appeler votre API à l’aide du flux de code d’autorisation avec PKCE.
    Page de connexion de l’application exemple
  2. Votre Auth0 Authorization Server redirige l’utilisateur vers la page de connexion, où il s’authentifie à l’aide de l’une des options de connexion configurées.
    Page de connexion Lock
  3. S’il s’agit de la première fois que l’utilisateur passe par ce flux, il voit un écran de consentement qui présente les permissions qu’Auth0 accordera à la SPA. Dans ce cas, on lui demande d’autoriser l’application à lire ses contacts et son calendrier.
    Écran de consentement Lock de l’application exemple
  4. Si l’utilisateur donne son consentement, Auth0 le redirige vers la SPA avec des jetons dans le fragment de hachage de l’URI. La SPA peut maintenant extraire les jetons du fragment de hachage à l’aide de JavaScript et utiliser le jeton d’accès pour appeler vos API au nom de l’utilisateur.
    Dans notre exemple, après vous être connecté avec succès, vous verrez des boutons qui vous permettront d’appeler l’une ou l’autre de vos API à l’aide du jeton d’accès obtenu auprès de l’API logique.
    Écran d’autorisation de l’utilisateur de l’application exemple

Mettre en œuvre la déconnexion unique (SLO) ou l’authentification unique (SSO)

Dans certains scénarios comportant plusieurs applications, où la déconnexion unique est souhaitée (lorsqu’un utilisateur se déconnecte d’une application, il doit aussi être déconnecté des autres applications), une application peut être configurée pour vérifier périodiquement auprès d’Auth0, à l’aide de checkSession(), si une session existe. Si aucune session n’existe, vous pouvez alors déconnecter l’utilisateur de l’application. La même méthode de vérification périodique peut être utilisée pour mettre en œuvre l’authentification silencieuse dans un scénario de (SSO). L’intervalle entre les vérifications effectuées au moyen de checkSession() devrait être d’au moins 15 minutes afin d’éviter tout problème futur lié à la limitation du débit de cette requête.

En savoir plus