Pérenniser votre authentification : passer des règles et des hooks aux actions

Auth0 est une plateforme de gestion des identités et des accès (IAM) qui simplifie la gestion de l'authentification et de l'autorisation dans les applications. Nous, les développeurs, nous sommes appuyés sur les règles et hooks Auth0 pour personnaliser le processus d'authentification. Cependant, avec l'introduction d'Auth0 Actions, il existe désormais une solution plus flexible, maintenable et moderne pour implémenter une logique d'authentification personnalisée.

Pourquoi la migration ?
À mesure que notre application grandissait, la gestion des règles et des hooks devenait difficile.
Les règles et les hooks s'exécutent de manière séquentielle, ce qui peut conduire à des résultats inattendus si l'un affecte l'autre, ce qui rend le dépannage difficile. De plus, les Hooks nécessitent une gestion séparée, ce qui ajoute à la complexité.

En revanche, même si les actions s'exécutent également de manière séquentielle, elles sont conçues pour être plus modulaires, ce qui nous permet de créer des éléments logiques plus petits et réutilisables. Cette modularité facilite le test et la correction des actions individuelles sans se soucier de la façon dont elles interagissent les unes avec les autres. Les actions fournissent également de meilleurs outils de débogage et de contrôle de version, simplifiant ainsi la gestion globale de notre processus d'authentification.

Limitations des règles et des crochets :

Les règles dans Auth0 sont des fonctions JavaScript qui s'exécutent dans le cadre du pipeline d'authentification. Bien que puissants, ils ont des limites :

• Ils s'exécutent de manière séquentielle, ce qui signifie que la gestion de plusieurs règles devient délicate.
• Le débogage et les tests peuvent être difficiles.
• Il n'y a pas de modularité, donc la même logique doit souvent être répétée.

Les crochets ont aussi des inconvénients :

• Ils sont basés sur des événements mais limités à certains scénarios comme l'inscription post-utilisateur.
• Ils nécessitent une gestion séparée en dehors du pipeline d'authentification habituel.
• Le débogage des hooks n'est pas aussi simple.

Avantages des actions :
Les actions résolvent bon nombre de ces problèmes :

• Ils permettent une meilleure modularité. vous pouvez les réutiliser dans différentes applications.
• Vous avez accès au contrôle de version, qui vous aide à gérer et à annuler les modifications.
• L'expérience de test et de débogage est considérablement améliorée, avec de meilleurs journaux et des outils de test en temps réel.
• Les actions peuvent être liées à divers déclencheurs (post-connexion, enregistrement préalable de l'utilisateur) , etc.) et peut être géré via une interface unifiée.

Préparer la migration

Documenter les règles et crochets existants :
Avant de commencer la migration, nous nous sommes assurés de documenter et d'identifier minutieusement les cas d'utilisation de toutes nos règles et hooks existants. Cela nous a aidé à mapper plus facilement les fonctionnalités aux actions.

Comprendre les actions Auth0 :
Les actions sont des fonctions basées sur des événements qui sont déclenchées à des points spécifiques du pipeline d'authentification, tels que la post-connexion ou la pré-inscription. Ils sont écrits en Node.js et vous permettent de définir votre logique de manière plus modulaire et réutilisable.

Les composants clés incluent :
Déclencheurs : spécifiez le moment où l'action est exécutée (par exemple, après la connexion, lors de l'inscription).
Gestionnaires d'événements : capturez les détails de l'événement qui a déclenché l'action (par exemple, les informations sur l'utilisateur).
Secrets : stockez des données sensibles telles que des clés API.
Contrôle de version : gérez différentes versions de vos actions pour des mises à jour et une restauration plus faciles.

Exemple de migration :
Prenons une règle simple qui ajoute des rôles d'utilisateur lors de la connexion :

function (user, context, callback) {
  // Check the user's email domain
  if (user.email && user.email.endsWith('@example.com')) {
    // Assign a role for users with the specified domain
    user.app_metadata = user.app_metadata || {};
    user.app_metadata.roles = ['employee'];

    // Update the user in the Auth0 database
    auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
      .then(function() {
        callback(null, user, context);
      })
      .catch(function(err) {
        callback(err);
      });
  } else {
    // Assign a default role for other users
    user.app_metadata = user.app_metadata || {};
    user.app_metadata.roles = ['guest'];

    callback(null, user, context);
  }
}

Explication :
Objectif : Cette règle vérifie si l'e-mail de l'utilisateur se termine par @example.com. Si c'est le cas, l'utilisateur se voit attribuer le rôle d'« employé ». Dans le cas contraire, ils se voient attribuer le rôle d'« invité ».
Mise à jour des métadonnées utilisateur : la règle utilise auth0.users.updateAppMetadata pour enregistrer le rôle attribué dans les métadonnées de l'application de l'utilisateur.
Callback : La règle appelle callback(null, user, context) pour continuer le flux d'authentification ou callback(err) si une erreur se produit.

La migration vers une action ressemble à ceci :

exports.onExecutePostLogin = async (event, api) => {
  // Check the user's email domain
  if (event.user.email && event.user.email.endsWith('@example.com')) {
    // Assign a role for users with the specified domain
    api.user.setAppMetadata('roles', ['employee']);
  } else {
    // Assign a default role for other users
    api.user.setAppMetadata('roles', ['guest']);
  }
};

Événement et API : l'action utilise un événement pour obtenir des informations sur l'utilisateur et une API pour modifier les métadonnées de l'utilisateur, tandis que la règle a directement manipulé l'objet utilisateur et utilisé un rappel.
Nature asynchrone : les actions sont conçues pour gérer les opérations asynchrones de manière plus propre, permettant une mise en œuvre plus simple.

Bonnes pratiques pour la migration des règles :
Gardez les actions petites : Décomposez la logique complexe en éléments plus petits et plus gérables.
Réutilisation dans plusieurs applications : écrivez des actions de manière à pouvoir être utilisées dans plusieurs applications pour éviter la duplication de code.

Prenons maintenant un simple crochet qui ajoute de la personnalité :

Les hooks sont des extensions côté serveur qui sont déclenchées par des événements spécifiques, tels que l'enregistrement post-utilisateur. Ils vous permettent d'intégrer une logique personnalisée dans le cycle de vie de l'utilisateur.

Exemple de crochet :

module.exports = function (client, scope, audience, context, cb) {

    let access_token = {
        scope: scope
    };

    if (client.name === 'MyApp') {
        access_token["https://app/persona"] = "user";

        if (context.body.customer_id || context.body.upin) {
            return cb(new InvalidRequestError('Not a valid request.'));
        }
    }
}

Dans une action, cela devient :

exports.onExecuteCredentialsExchange = async (event, api) => {
    let requestBody = event.request.body;
    if (event.client.name === 'MyApp') {
        api.accessToken.setCustomClaim(`https://app/persona`, "user");
        if (!requestBody.customer_id || !requestBody.upin) {
            api.access.deny(`Not a valid request for client-credential Action`);
            return
        }
    }

Différences de mise en œuvre :

• Les actions fournissent de meilleurs outils pour gérer le code asynchrone et la gestion des erreurs.
• Le processus de migration simplifie le débogage grâce au suivi des journaux intégré ng.

Test et débogage :
L'interface d'actions d'Auth0 facilite les tests, avec des journaux en temps réel et la possibilité de simuler des événements. Nous avons largement utilisé la fonctionnalité de journalisation des tâches Web en temps réel pour nous assurer que les actions fonctionnaient comme prévu.

Avantages expérimentés après la migration :
Améliorations des performances :
Nous avons observé que les actions s'exécutent plus rapidement et sont plus prévisibles, car l'exécution séquentielle des règles entraînait souvent des goulots d'étranglement dans les performances.

Flux de travail simplifié :
Grâce aux actions, il est devenu plus facile de gérer une logique personnalisée. Nous disposons désormais d'actions modulaires qui sont réutilisées dans différentes applications, ce qui réduit la duplication du code.

Réutilisabilité et modularité :
Les actions ont amélioré notre capacité à réutiliser la logique sur plusieurs locataires. Auparavant, nous devions dupliquer des règles pour différentes applications, mais désormais, une seule action peut servir à plusieurs fins.

Pièges courants à éviter :
Malentendus concernant l'ordre d'exécution :
Si vous exécutez plusieurs actions, assurez-vous de comprendre l'ordre dans lequel elles sont exécutées. Un mauvais ordre d'exécution peut entraîner des problèmes tels que l'attribution de rôles d'utilisateur incorrects.

Déclencheurs mal configurés :
Vérifiez à nouveau que les bons déclencheurs sont attribués à vos actions.
Par exemple, attacher une action post-connexion à un événement d'inscription préalable à l'utilisateur ne fonctionnera pas.

Tests en production :
Testez toujours d’abord dans un environnement de test. Ne déployez jamais une action non testée directement en production.

En conclusion, migrer vers Auth0 Actions a changé la donne pour nous. Avec la dépréciation d'Auth0 Rules and Hooks le 18 novembre 2024, cette transition a simplifié notre flux de travail, amélioré les performances et rendu la gestion de la logique d'authentification beaucoup plus facile. Si vous comptez toujours sur les règles et les crochets, c'est le moment idéal pour explorer les actions : vous ne le regretterez pas !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!