Skip to main content
ルールとHooksのサポート終了 (EOL) 日は 2026 年 11 月 18 日 です。また、2023 年 10 月 16 日 以降に作成された新しいテナントでは、これらはすでに利用できません。アクティブな Hooks を使用している既存のテナントは、提供終了まで Hooks 製品へのアクセスを維持できます。Auth0 を拡張するには、Actions の使用を強くお勧めします。Actions では、豊富な型情報、インラインドキュメント、公開 npm パッケージを利用できるほか、拡張機能の活用をさらに広げる外部連携にも接続できます。Actions の機能の詳細については、Auth0 Actions の仕組みを理解するをお読みください。移行を支援するために、Rules から Actions への移行および Hooks から Actions への移行 に役立つガイドを提供しています。また、機能比較、Actions のデモ、移行を進めるうえで役立つその他のリソースを紹介した専用の Move to Actions ページも用意しています。ルールとHooksの非推奨化の詳細については、ブログ記事「Rules と Hooks のサポート終了に向けた準備」をお読みください。
事前設定された認可ポリシーにルールを追加することで、ユーザーアクセスの許可または拒否をより細かく制御できます。ルールには、適切なロジックに基づいて認可の判断を行うカスタムコードが含まれます。ほかのルールと組み合わせることで、さまざまな状況で何が起こるかを定義するのに役立ちます。 ルールでは、ユーザーの部門、時刻、場所、またはその他のユーザー属性や API 属性 (ユーザー名、セキュリティクリアランス、API 名など) といった、ユーザーに保存されている属性の任意の組み合わせに基づいてアクセスを制限できます。 たとえば、非営利団体で細かなアクセス制御を実現するためにルールを使用している場合、ニューデリー オフィスの研究開発部門で働く W2 従業員だけに、あるアプリケーションへのアクセスを許可できます。 認可ポリシーでのルール実装のサンプルについては、サンプルユースケース: 認可でのルールをお読みください。

​
認可プロセスにおけるルール

ルールは実行される順序に応じて、権限がに追加される前に、認可の判断結果を変更できます。ルールを含む基本的なプロセスは次のとおりです。
  1. ユーザーがアプリケーションでの認証を試みます。
  2. Auth0 はリクエストを選択されたアイデンティティプロバイダーに送ります。
  3. アイデンティティプロバイダーがユーザーの資格情報が有効であることを確認すると、作成済みのすべてのルールが Auth0 Dashboard で設定された順序どおりに実行されます。
  4. どのルールでもユーザーのアクセスが制限されていなければ、ユーザーにはアプリケーションへのアクセスが認可されます。

​
詳しくはこちら