Meilleures pratiques de l’environnement des règles

Les règles s’exécutent comme une série de fonctions JavaScript appelées dans une instance d’un conteneur Webtask sans serveur Auth0. Dans ce cadre, un environnement déterminé est fourni, ainsi qu’un certain nombre d’artefacts fournis à la fois par le conteneur et par le serveur d’authentification Auth0 (votre locataire Auth0) en tant que tel.

Les conteneurs Webtask sans serveur Auth0 peuvent utiliser une large gamme de modules npm; les modules npm réduisent non seulement la taille globale de l’implémentation du code de règle, mais ils fournissent également un accès à une large gamme de fonctionnalités prédéfinies.

Par défaut, une grande liste de modules npm accessibles au public est prise en charge immédiatement. Cette liste a été compilée et vérifiée pour écarter tout problème de sécurité potentiel. Pour voir la liste, veuillez consulter la section Puis-je exiger : extensibilité Auth0.

Si vous avez besoin d’un module npm qui n’est pas pris en charge, vous pouvez en faire la demande sur le portail d’assistance Auth0 ou par l’intermédiaire de votre représentant Auth0. Auth0 évalue les demandes pour déterminer leur pertinence. Il n’y a actuellement aucune prise en charge dans Auth0 pour l’utilisation de modules npm à partir de référentiels privés. De nouveaux packages sont généralement ajoutés aux deux semaines sur demande. Les packages existants sont rarement supprimés, car cela entraînerait des changements de règles. Gardez à l’esprit que les packages Auth0 sont stockés avec les versions dans un registre interne et ne sont pas synchronisés avec npm.

Lorsque vous utilisez des modules npm pour accéder à des services externes, réduisez au minimum les demandes d’API, évitez les appels excessifs vers des services payants et évitez toute exposition potentielle à la sécurité en limitant ce qui est envoyé. Pour en savoir plus, veuillez lire Meilleures pratiques en matière de performances.

Lorsque vous demandez un module dans une règle, si la version n’est pas précisée, le gestionnaire de package utilise la première version qu’il trouve dans la liste interne. Il est possible de préciser une version pour forcer le gestionnaire de package à utiliser une autre version que celle par défaut. Cela permet au code de la règle de profiter des corrections ou des fonctionnalités de la version indiquée qui ne sont pas proposées dans la version par défaut du module.

Les règles d'Auth0 prennent en charge les variables d’environnement, accessibles par l’objet de configuration globalement accessible. La configuration devrait être traitée en lecture seule, et devrait être utilisée pour stocker des informations sensibles comme des authentifiants ou des clés API permettant d’accéder au service externe. Cela empêchera d’avoir des valeurs sensibles du point de vue de la sécurité codées en dur dans une règle. Elle peut également être utilisée pour soutenir les stratégies de meilleures pratiques du cycle de vie du développement logiciel (SDLC) que vous utilisez en vous permettant de définir des variables qui ont des valeurs propres aux locataires. Cela empêche d’avoir des valeurs codées en dur dans une règle qui peut changer en fonction du locataire qui l’exécute.

Les conteneurs Webtask sans serveur Auth0 sont approvisionnés à partir d’une banque associée à chaque locataire Auth0. Chaque instance de conteneur met à disposition l’objet global, accessible dans toutes les règles qui s’exécutent dans l’instance de conteneur. L’objet global agit comme une variable globale et peut être utilisé pour définir des informations, ou même pour définir des fonctions qui peuvent être utilisées dans toutes les règles (qui s’exécutent dans le conteneur), quelle que soit l’instance du pipeline :

global.tokenVerify = global.tokenVerify || function(token, secret) {
      /* The 'jwt.verify' function is synchronous, however wrapping with a promise
      * provides for better error management and integration within the logic
      * flow.
      */
      return new Promise(function(resolve, reject) {
      jwt.verify(
    token,
    secret,{
    clockTolerance: 5},
    function(err, decoded) {
      if (err) {
    reject(err);
      } else {
    resolve(decoded);
      }
      });
    });
    };

L’objet global peut également être utilisé pour mettre en cache des ressources coûteuses, telles qu’un jeton d’accès pour une API tierce (p. ex., la journalisation) qui fournit une fonctionnalité non propre à l’utilisateur ou un jeton d’accès à votre propre API défini dans Auth0 et obtenu en utilisant le flux des identifiants client.

Les règles peuvent s’exécuter plus d’une fois lorsqu’un pipeline est exécuté, et cela dépend du contexte de l’opération. Pour chaque contexte dans lequel une règle est exécutée, une instance de conteneur existante est soit fournie à partir de la banque de locataires Auth0, soit instanciée à nouveau. Pour chaque instanciation d’un nouveau conteneur Webtask, l’objet global est réinitialisé. Ainsi, toute déclaration dans l’objet global devrait également inclure une disposition pour l’initialisation (comme indiqué ci-dessus), idéalement avec cette déclaration faite le plus tôt possible (c’est-à-dire dans une règle qui s’exécute tôt dans l’ordre d’exécution).

L’objet auth0 est une instance spécialement restreinte de ManagementClient (définie dans la bibliothèque client node-auth0 Node.js) et fournit un accès limité à Management API Auth0. Il est principalement utilisé pour mettre à jour les métadonnées associées à l’objet user (utilisateur) à partir d’une règle.

En plus d’être restreint (c.-à-d. qu’il prend en charge un nombre limité de méthodes ManagementClient pour l’accès utilisateur uniquement), les permissions du jeton d’accès associé à l’objet auth0 sont limitées à read:users et à update:users. En règle générale, tout cela est suffisant pour la majorité des opérations que nous recommandons d’effectuer à partir d’une règle. Cependant, si vous avez besoin d’accéder à l’ensemble des méthodes prises en charge ou d’accéder à des permissions supplémentaires, vous devrez utiliser un autre moyen d’accès à Management API.

Cet autre accès à l’API à partir d’une règle est généralement obtenu en instanciant une instance indépendante de ManagementClient. Vous aurez ainsi accès à toutes les fonctionnalités actuelles, y compris la logique des tentatives automatiques en cas d’erreurs 429 résultant d’une politique de limite anti-attaques. En outre, si vous n’avez besoin que des permissions par défaut, vous pouvez même initialiser la nouvelle instance à l’aide du jeton d’accès associé à l’objet auth0.

Comme l’objet context (contexte), l’objet auth0 contient des informations sensibles pour la sécurité; vous ne devez donc pas les transmettre à un service externe ou tiers. En outre, Management API Auth0 présente à la fois une limite anti-attaques et une certaine latence; vous devez donc être judicieux quant à la fréquence des appels. Pour en savoir plus sur les objets context (contexte), consultez la page Meilleures pratiques sur l’exécution des règles.

Utilisez l’objet auth0 (et tout autre mécanisme pour appeler Management API Auth0) avec parcimonie et utilisez une gestion adéquate des exceptions et des erreurs pour éviter toute interruption inattendue de l’exécution du pipeline.

• Meilleures pratiques concernant l’anatomie des règles
• Meilleures pratiques d’exécution des règles
• Meilleures pratiques en lien aux règles de sécurité
• Meilleures pratiques de test des règles
• Meilleures pratiques de la gestion des erreurs