Configurer une API logique pour plusieurs API

Si vous avez plusieurs implémentations d’API distinctes qui font toutes logiquement partie de la même API, vous pouvez simplifier votre processus d’autorisation en les représentant avec une API logique unique dans Auth0 Dashboard. Cela vous permet de mettre en œuvre un seul flux d’autorisation, tout en contrôlant l’accès aux API individuelles en leur attribuant les permissions appropriées.

Les sections suivantes décrivent comment utiliser et représenter plusieurs API en tant que serveur de ressources unique dans Auth0. Nous utiliserons l’exemple d’application suivant dans les exemples. L’exemple d’application utilise une architecture de microservices et contient :

• Deux API Node.js : contacts et calendar (à considérer comme microservices).

• Un serveur de ressources représentant les deux API.

• Deux permissions à espace de noms : read:contacts et read:calendar

• Le flux d’autorisation implicite pour obtenir un access_token qui fonctionne avec les deux API.

Nous représenterons les deux API à l’aide d’une seule API Auth0 appelée Organizer Service. Nous allons ensuite créer deux permissions pour démontrer comment vous pouvez utiliser le flux implicite pour accéder aux API calendar et contacts à partir de l’application Web monopage.

Vous devez effectuer ce qui suit :

1. Activer une connexion pour votre application.

2. Créer un utilisateur de test.

3. Enregistrer une API logique dans Auth0.

4. Configurer des permissions 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).

• Enregistrer votre application.

  • Sélectionnez un type d ’application d’application à page unique.

  • Ajoutez les Callback URL autorisées de http://localhost:3000 et http://localhost:3000/callback.html.

• Téléchargez l’ exemple d’application. Pour savoir comment configurer l’application d’exemple, consultez le fichier README.

Vous aurez besoin d’une source d’utilisateurs pour votre application nouvellement enregistrée, vous devrez donc configurer une connexion. Pour les besoins de cet exemple, nous allons créer une simple connexion par base de données qui ne demande que l’adresse courriel et le mot de passe de l’utilisateur. Pour en savoir plus, consultez Connexions par base de données.

Since you’re working with a newly-created connection, there won’t be any users associated with it. Before we can test the sample application’s login process, we’ll need to create and associate a user with the connection, so make sure you choose your newly-created Connection when you create your user. To learn more, read Create Users.

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

Pour permettre à l’API logique de représenter les API incluses dans l’exemple d’application, vous devrez créer les autorisations appropriées (permissions).

Les permissions vous permettent de définir les actions de l’API qui seront accessibles aux applications appelantes. Une permission représente une combinaison API/action. Dans le cadre de cet exemple, vous souhaitez que les applications appelantes puissent read les données d’une API appelée calendar et une autre appelée contacts, vous devez donc créer les autorisations suivantes :

• read:calendar

• read:contacts

Vous pouvez considérer chacune de ces API comme un microservice. Pour en savoir plus, lisez Ajout de permissions API et Permissions des API.

Vous êtes maintenant prêt à donner accès à vos API en permettant à l’API logique d’obtenir des jetons d’accès. En incluant les permissions 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 répond le mieux à vos besoins. Par exemple :

• Si vous avez une Application de communication entre machines , vous pouvez l’autoriser à demander des jetons d’accès à votre API en exécutant un flux des identifiants client.

• Si vous créez une application native, utilisez le Flux de code d’autorisation avec Proof Key for Code Exchange (PKCE).

Pour en savoir plus sur les flux d’autorisation, consultez Flux d’authentification et d’autorisation.

1. L’utilisateur clique sur Connexion dans l’application Web monopage, et l’application le redirige vers le serveur d’autorisation Auth0 (point de terminaison /authorize). Pour en savoir plus sur les paramètres de l’appel, consultez notre tutoriel : Appeler votre API avec le flux de code d’autorisation avec PKCE.

   codeblockOld.header.login.logInButton codeblockOld.header.login.configureSnippet

   https://{yourDomain}/authorize?
   scope=read:contacts%20read:calendar&
   audience=organize&
   response_type=id_token%20token&
   client_id={yourClientId}&
   redirect_uri=http://localhost:3000&
   nonce={nonce}

   Was this helpful?

   Yes /No
   

2. Votre serveur d’autorisation Auth0 redirige l’utilisateur vers la page de connexion, où l’utilisateur s’authentifie en utilisant l’une des options de connexion configurées.

   

3. Si c’est la première fois que l’utilisateur passe par ce flux, il voit une invite de consentement listant les autorisatoins qu’Auth0 donnera à l’application Web monopage. Dans ce cas, on demande à l’utilisateur de donner son consentement pour que l’application puisse accéder à ses contacts et à son calendrier.

   

4. Si l’utilisateur donne son accord, Auth0 le redirige vers l’application Web monopage avec des jetons dans le fragment de hachage de l’URI. L’application monopage peut alors 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.

   function getParameterByName(name) {
     var match = RegExp('[#&]' + name + '=([^&]*)').exec(window.location.hash);
     return match && decodeURIComponent(match[1].replace(/\+/g, ' '));
   }
   
   function getAccessToken() {
     return getParameterByName('access_token');
   }

   Was this helpful?

   Yes /No

Dans notre exemple, après avoir réussi à vous connecter, 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.

Dans certains scénarios multi-applications où la déconnexion unique est souhaitée (c’est-à-dire qu’un utilisateur se déconnectant d’une application doit également être déconnecté des autres applications), une application peut être configurée pour interroger périodiquement Auth0 en utilisant checkSession() pour voir si une session existe. Si la session n’existe pas, vous pouvez alors déconnecter l’utilisateur de l’application. La même méthode d’interrogation peut être mise en place pour une authentification silencieuse dans un scénario d’authentification unique (SSO).

L’intervalle d’interrogation entre les vérifications de checkSession() devrait être d’au moins 15 minutes entre chaque appel pour éviter tout problème ultérieur lié à la limite anti-attaques de cet appel.

• Enregistrer les API
• Ajouter des autorisations API
• Permissions des API
• Vérifier les appels d’API