Bonnes pratiques pour les scripts d’action de base de données

Consultez nos recommandations pour optimiser les performances et la fiabilité des scripts d’action de base de données personnalisée.

​

Accès sécurisé à votre répertoire d’utilisateurs externe

Lorsque vous utilisez une connexion à une base de données personnalisée, vous devez fournir une interface permettant à Auth0 de se connecter à votre répertoire d’utilisateurs.

Rendre votre répertoire d’utilisateurs largement accessible sur Internet comporte des risques importants. Par exemple, les interfaces SQL et celles d’autres bases de données offrent de nombreuses fonctionnalités, et les rendre généralement accessibles contrevient au principe du moindre privilège.

​

Fournir un accès au moyen d’une API protégée

Nous recommandons de fournir l’accès au moyen d’une API dotée d’un nombre limité de points de terminaison protégés, afin d’exécuter uniquement les fonctions de gestion des utilisateurs requises pour la connexion à une base de données personnalisée, comme la consultation d’un utilisateur et la modification du mot de passe.

La protection de cette API à l’aide d’un jeton d’accès vous permet d’utiliser le flux d’octroi des informations d’identification du client à partir d’un script d’action. Vous pouvez ensuite mettre le jeton en cache pour le réutiliser dans l’objet global afin d’améliorer les performances.

Si votre répertoire d’utilisateurs externe dispose d’une API, ou si vous en implémentez une vous-même, vous pouvez enregistrer l’API dans Auth0 et créer une action afin de restreindre l’accès des utilisateurs finaux.

Par défaut, Auth0 peut vous fournir un jeton pour n’importe quelle API si vous vous authentifiez avec succès et incluez l’audience appropriée. Restreindre l’accès à l’API de votre répertoire d’utilisateurs en limitant l’attribution des jetons d’accès permet de prévenir les utilisations non autorisées en n’accordant l’accès qu’au moyen d’informations d’identification de client précises. Cela atténue plusieurs scénarios d’attaque, par exemple lorsqu’un acteur malveillant intercepte des redirections vers /authorize et ajoute l’audience à l’API.

Si votre répertoire d’utilisateurs externe ne dispose pas d’une API et qu’il n’est pas possible d’en implémenter une, vous pouvez tout de même rédiger vos scripts d’action pour communiquer directement avec lui.

​

Restreindre l’accès au réseau

Nous recommandons de restreindre l’accès à votre répertoire d’utilisateurs externe au moyen d’une liste d’adresses IP autorisées comprenant les adresses IP sortantes d’Auth0, afin d’autoriser le trafic entrant provenant d’Auth0.

Comme les adresses IP sortantes d’Auth0 sont partagées entre tous les tenants Auth0 d’une région donnée, nous déconseillons d’utiliser une telle liste comme unique méthode pour sécuriser l’accès à votre répertoire d’utilisateurs. Utilisez plutôt une liste d’adresses IP autorisées parmi plusieurs mesures de sécurité.

​

Délai d’expiration des requêtes asynchrones et externes

Si vous appelez un service externe ou une API dans votre script d’action, configurez la fonction pour qu’elle expire après un délai raisonnable et renvoyez une erreur si le service externe ou l’API est inaccessible.

Exemple d’objet Promise

Cet exemple utilise la méthode JavaScript intégrée fetch, qui récupère une ressource sur un réseau, puis renvoie un objet Promise, en utilisant des chaînes de promesses.

async function login(userNameOrEmail, password, callback) {
  try {
    const apiEndpoint = 'https://example.com/api/authenticate';
    
    const options = {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({
        email: userNameOrEmail,
        password: password // Envoyer en texte brut en HTTPS; l’API le vérifie
      })
    };

    const response = await fetch(apiEndpoint, options);

    if (!response.ok) {
      return callback(new Error(`HTTP error! Status: ${response.status}`));
    }

    const result = await response.json();

    if (result.err) {
      return callback(new Error(`Error authenticating user: ${result.err}`));
    }

    const profile = {
      email: result.profileData.email,
      username: result.profileData.username
    };

    return callback(null, profile);
  } catch (err) {
    return callback(err);
  }
}

Exemple de fonction asynchrone

Cet exemple utilise la méthode JavaScript intégrée fetch, qui récupère une ressource sur un réseau, puis renvoie un objet Promise, en utilisant des fonctions asynchrones.

⏺ async function login(userNameOrEmail, password, callback) {
    try {
      const apiEndpoint = 'https://example.com/api/authenticate';
      const options = {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json'
        },
        body: JSON.stringify({
          email: userNameOrEmail,
          password: password
        })
      };

      const response = await fetch(apiEndpoint, options);
  
      if (!response.ok) {
        return callback(new Error(`HTTP error! Status: ${response.status}`));
      }

      const result = await response.json();
  
      if (result.err) {
        return callback(new Error(`Error authenticating user: ${result.err}`));
      }

      const profile = {
        email: result.profileData.email,
        username: result.profileData.username
      };

      return callback(null, profile);
    } catch (err) {
      return callback(err);
    }
  }

Vous pouvez renvoyer des erreurs à partir de scripts d’action de base de données personnalisée en les transmettant à la fonction callback. Nous recommandons d’utiliser des messages d’erreur descriptifs pour faciliter le dépannage et le débogage.

​

Évitez les fonctions anonymes

Vous pouvez implémenter des scripts d’action sous forme de fonctions anonymes, mais nous recommandons d’utiliser des fonctions nommées, car les fonctions anonymes peuvent compliquer l’interprétation de la pile d’appels lors du débogage de conditions d’erreur.

​

Récupérer les jetons du fournisseur d’identité

Si l’objet user renvoie les propriétés access_token et refresh_token, Auth0 les traite différemment des autres renseignements sur l’utilisateur. Auth0 les stocke dans la propriété identities de l’objet user :

{
	"email": "[e-mail]",
	"updated_at": "2019-03-15T15:56:44.577Z",
	"user_id": "auth0|some_unique_id",
	"nickname": "a_nick_name",
	"identities": [ 
		{
			"user_id": "some_unique_id",
			"access_token": "e1b5.................92ba",
			"refresh_token": "a90c.................620b",
			"provider": "auth0", 
			"connection": "custom_db_name",
			"isSocial": false 
		}
  ], 
  "created_at": "2019-03-15T15:56:44.577Z",
  "last_ip": "192.168.1.1",
  "last_login": "2019-03-15T15:56:44.576Z",
  "logins_count": 3
}

Pour récupérer l’une ou l’autre de ces propriétés à l’aide de l’API de gestion d’Auth0 Management API, incluez la portée read:user_idp_tokens lorsque vous demandez un jeton d’accès.