将来性のある認証: ルールとフックからアクションへの移行-jsチュートリアル-php.cn

Future-Proofing Your Authntegration: Moving from Rules and Hooks to Actions

Auth0 は、アプリケーションでの認証と認可の管理を簡素化する ID およびアクセス管理 (IAM) プラットフォームです。私たち開発者は、Auth0 ルールとフックを利用して認証プロセスをカスタマイズしてきました。ただし、Auth0 アクションの導入により、カスタム認証ロジックを実装するための、より柔軟で保守しやすい最新のソリューションが提供されるようになりました。

移行の理由
アプリケーションが成長するにつれて、ルールとフックの管理が困難になってきました。
ルールとフックは両方とも順番に実行されるため、一方が他方に影響を与えると予期しない結果が生じる可能性があり、トラブルシューティングが困難になります。さらに、フックは個別に管理する必要があるため、複雑さが増します。

対照的に、アクションも順次実行されますが、よりモジュール化されるように設計されているため、より小さく再利用可能なロジックを作成できます。このモジュール性により、個々のアクションが相互にどのように相互作用するかを気にすることなく、個々のアクションのテストと修正が容易になります。アクションは、より優れたデバッグツールとバージョン管理も提供し、認証プロセスの全体的な管理を簡素化します。

ルールとフックの制限:

Auth0 のルールは、認証パイプラインの一部として実行される JavaScript 関数です。強力ではありますが、次のような制限があります。

これらは順番に実行されるため、複数のルールの管理が難しくなります。
デバッグとテストは困難な場合があります。
モジュール性がないため、同じロジックを繰り返す必要があることがよくあります。

フックには欠点もあります:

これらはイベント駆動型ですが、ユーザー登録後のような特定のシナリオに限定されます。
通常の認証パイプラインの外側で個別に管理する必要があります。
フックのデバッグはそれほど簡単ではありません。

アクションの利点:
アクションはこれらの問題の多くを解決します:

これにより、モジュール性が向上します。さまざまなアプリケーション間で再利用できます。
変更の管理とロールバックに役立つバージョン管理にアクセスできます。
より優れたログとリアルタイムテストツールにより、テストとデバッグのエクスペリエンスが大幅に向上しました。
アクションはさまざまなトリガーに関連付けることができます (ログイン後、ユーザー登録前) 、など）、統一されたインターフェイスを通じて管理できます。

移行の準備

既存のルールとフックを文書化します:
移行を開始する前に、既存のルールとフックすべてのユースケースを徹底的に文書化し、特定するようにしました。これにより、機能をアクションにマッピングするのがより簡単になりました。

Auth0 アクションについて:
アクションは、ログイン後や事前登録など、認証パイプラインの特定の時点でトリガーされるイベント駆動型の関数です。これらは Node.js で記述されており、よりモジュール化された再利用可能な方法でロジックを定義できます。

主なコンポーネントは次のとおりです:
トリガー: アクションがいつ実行されるかを指定します (ログイン後、登録中など)。
イベントハンドラー: アクションをトリガーしたイベントから詳細を取得します (ユーザー情報など)。
シークレット: API キーなどの機密データを保存します。
バージョン管理: アクションのさまざまなバージョンを管理して、更新とロールバックを簡単にします。

移行の例:
ログイン時にユーザーの役割を追加する簡単なルールを考えてみましょう:

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);
  }
}

ログイン後にコピー

説明:
目的: このルールは、ユーザーの電子メールが @example.com で終わるかどうかを確認します。存在する場合、ユーザーには「従業員」の役割が割り当てられます。それ以外の場合は、「ゲスト」の役割が割り当てられます。
ユーザーメタデータの更新: ルールは auth0.users.updateAppMetadata を使用して、割り当てられたロールをユーザーのアプリメタデータに保存します。
Callback: ルールは callback(null, user, context) を呼び出して認証フローを続行するか、エラーが発生した場合は callback(err) を呼び出します。

これをアクションに移行すると次のようになります:

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']);
  }
};

ログイン後にコピー

イベントと API: アクションはイベントを使用してユーザー情報を取得し、API を使用してユーザーのメタデータを変更しますが、ルールはユーザーオブジェクトを直接操作し、コールバックを使用します。
非同期の性質: アクションは非同期操作をよりクリーンに処理するように設計されており、より簡単な実装が可能です。

ルールを移行するためのベストプラクティス:
アクションを小さく保つ: 複雑なロジックをより小さく、より管理しやすい部分に分割します。
アプリケーション全体で再利用: コードの重複を避けるために、複数のアプリケーションで使用できる方法でアクションを作成します。

次に、ペルソナを追加する簡単なフックを見てみましょう:

フックは、ユーザー登録後などの特定のイベントによってトリガーされるサーバー側の拡張機能です。これにより、カスタムロジックをユーザーのライフサイクルに統合できます。

フックの例:

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.'));
        }
    }
}

ログイン後にコピー

アクションでは次のようになります:

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
        }
    }

ログイン後にコピー

実装の違い:

アクションは、非同期コードとエラー処理を処理するためのより優れたツールを提供します。
移行プロセスでは、統合されたログ追跡によりデバッグが簡素化されます。 NG。

テストとデバッグ:
Auth0 のアクションインターフェイスにより、リアルタイムログとイベントをシミュレートする機能により、テストが簡単になります。アクションが期待どおりに動作することを確認するために、リアルタイム Web タスクログ機能を広範囲に使用しました。

移行後に体験したメリット:
パフォーマンスの改善:
ルールの順次実行はパフォーマンスのボトルネックにつながることが多いため、アクションの実行が速くなり、予測可能であることがわかりました。

簡素化されたワークフロー:
アクションにより、カスタムロジックの管理が容易になりました。さまざまなアプリケーション間で再利用できるモジュール式アクションが提供されるようになり、コードの重複が減りました。

再利用性とモジュール性:
アクションにより、複数のテナント間でロジックを再利用する機能が向上しました。以前は、さまざまなアプリケーションに対してルールを複製する必要がありましたが、現在は 1 つのアクションで複数の目的を果たせるようになりました。

避けるべき一般的な落とし穴:
実行命令の誤解:
複数のアクションを実行している場合は、それらの実行順序を必ず理解してください。実行順序が間違っていると、間違ったユーザーロールが割り当てられるなどの問題が発生する可能性があります。

トリガーの構成が間違っています:
正しいトリガーがアクションに割り当てられていることを再確認してください。
たとえば、ログイン後のアクションをユーザー登録前のイベントに添付しても機能しません。

本番環境でのテスト:
必ず最初にステージング環境でテストしてください。テストされていないアクションを本番環境に直接デプロイしないでください。

結論として、Auth0 Actions への移行は私たちにとって大きな変化でした。 Auth0 は 2024 年 11 月 18 日にルールとフックを非推奨にするため、この移行によりワークフローが簡素化され、パフォーマンスが向上し、認証ロジックの管理がはるかに簡単になりました。まだルールとフックに依存している場合は、今がアクションを検討するのに最適な時期です。後悔はしないでしょう!

以上が将来性のある認証: ルールとフックからアクションへの移行の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。