> ## Documentation Index > Fetch the complete documentation index at: https://docs-dev-docs-event-stream-action-templates.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # サンプルユースケース：認可を使ったルール > ルールとRole-Based Access Control（RBAC）の使い方について説明します。Authorization Core（認可コア）機能セットで使用するものです。 RulesとHooksのサポート終了（EOL）日は**2026年11月18日** であり、**2023年10月16** 日の時点で作成された新しいテナントは使用できなくなります。Hooksが有効な既存のテナントは、サポート終了までHooksを利用できます。 今後はActionsに移行して、Auth0の機能を拡張することを強くお勧めします。Actionsを使用すると、豊富な情報やインラインドキュメント、パブリック`npm`パッケージにアクセスして、外部統合を使って全体的な拡張エクスペリエンスを強化することができます。Actionsの詳細については、「[Auth0 Actionsの仕組みを理解する](/docs/ja-jp/customize/actions/actions-overview)」をお読みください。 当社では、移行の参考資料として、[RulesからActionsへの移行](/docs/ja-jp/customize/actions/migrate/migrate-from-rules-to-actions)と[HooksからActionsへの移行](/docs/ja-jp/customize/actions/migrate/migrate-from-hooks-to-actions)に関するガイドを提供しています。また、専用の「[Actionsへの移行](https://auth0.com/extensibility/movetoactions)」ページでは、機能の比較や[Actionsのデモ](https://www.youtube.com/watch?v=UesFSY1klrI)、その他のリソースを掲載して、円滑な移行をサポートしています。 RulesとHooksの廃止の詳細については、当社のブログ記事「[RulesとHooksの提供終了について](https://auth0.com/blog/preparing-for-rules-and-hooks-end-of-life/)」をお読みください。 [ルール](/docs/ja-jp/customize/rules)を使うことで、事前構成された[認可ポリシー](/docs/ja-jp/manage-users/access-control/authorization-policies)の決定結果を修正または補完できるため、[Role-based Access Control（RBAC）](/docs/ja-jp/manage-users/access-control/rbac)だけでは対応できないより複雑なケースを処理することができます。ルールは実行順序に基づいて、アクセストークンにアクセス許可が追加される前に、認可での決定を変更することができます。また、トークンの内容をカスタマイズすることもできます。 ## 特定のアプリケーションに平日のみのアクセスを許可する たとえば、平日のみにアクセスを許可したいアプリケーションがあるとします。これを行うには、[以下のルールを作成します](/docs/ja-jp/customize/rules/create-rules)。 ```javascript lines theme={null} function (user, context, callback) { if (context.clientName === 'APP_NAME') { const d = Date.getDay(); if (d === 0 || d === 6) { return callback(new UnauthorizedError('This app is only available during the week.')); } } callback(null, user, context); } ``` ユーザーが週末にアプリケーションにアクセスしようとした場合には、たとえ認証され、適切な権限があったとしても、アクセスが拒否されます。 ## 企業ネットワーク内部のユーザーにのみアクセスを許可する たとえば、アプリケーションへのアクセスを許可するのに、企業ネットワークの内側からアクセスするユーザーに限定したいとします。これを行うには、以下のルールを作成します。 ```javascript lines theme={null} function (user, context, callback) { const ipaddr = require('ipaddr.js@1.9.0'); const corp_network = "192.168.1.134/26"; const current_ip = ipaddr.parse(context.request.ip); if (!current_ip.match(ipaddr.parseCIDR(corp_network))) { return callback(new UnauthorizedError('This app is only available from inside the corporate network.')); }; callback(null, user, context); } ``` ユーザーが企業ネットワークの外側にいる場合には、たとえ認証に成功して、適切な権限があったとしても、アクセスが拒否されます。 ## APIを呼び出すユーザーすべてのアクセスを拒否する たとえば、APIを呼び出すユーザーのすべてに対して、アクセスを拒否したいとします。つまり、[［Dashboard］ > ［Applications（アプリケーション）］ > ［APIs］](https://manage.auth0.com/#/apis)の**APIオーディエンス** フィールドに記載されたAPIの`オーディエンス`の値に基づいてアクセスを拒否する必要があります。これを行うには、以下のルールを作成します。 ```javascript lines theme={null} function (user, context, callback) { /* * Denies access to user-based flows based on audience */ var audience = ''; audience = audience || (context.request && context.request.query && context.request.query.audience) || (context.request && context.request.body && context.request.body.audience); if (audience === 'http://todoapi2.api' || !audience) { return callback(new UnauthorizedError('end_users_not_allowed')); } return callback(null, user, context); } ``` この場合、APIの`オーディエンス`の値は`http:://todoapi2.api`であり、これが拒否する対象となるオーディエンスです。誰かがこの`オーディエンス`値でAPIへのアクセスを試みた場合、アクセスが拒否され、`HTTP 401`応答を受け取ります。 ## ユーザーのロールをトークンに追加する 「Add Permissions in the Access Token（アクセストークンに許可を追加）」と一緒に[APIのRBACを有効にした場合](/docs/ja-jp/get-started/apis/enable-role-based-access-control-for-apis)（またはManagement APIを介してRBACを有効にし、**［Token Dialect（トークンダイアレクト）］** を`access_token_authz`に設定した場合）、アクセストークンでユーザー権限を受け取ります。ユーザーのロールをトークンに追加するには、以下のルールを作成するときに`context.authorization`オブジェクトを使用します。 ```javascript lines theme={null} function (user, context, callback) { const namespace = 'http://demozero.net'; const assignedRoles = (context.authorization || {}).roles; let idTokenClaims = context.idToken || {}; let accessTokenClaims = context.accessToken || {}; idTokenClaims[`${namespace}/roles`] = assignedRoles; accessTokenClaims[`${namespace}/roles`] = assignedRoles; context.idToken = idTokenClaims; context.accessToken = accessTokenClaims; callback(null, user, context); } ``` ## Authorization Core（認可コア）機能セットでDelegated Administration Extension（DAE、委任管理拡張機能）を管理する [Delegated Administration Extension（DAE：委任管理拡張機能）](/docs/ja-jp/customize/extensions/delegated-administration-extension)とAuthorization Core（認可コア）は全く別の機能ですが、ルールを使用する場合、Authorization Core（認可コア）機能セットを使用すると、DAEのロールを作成し、管理することができます。 1. Authorization Core（認可コア）機能セットを使用して[DAEロールを作成します](/docs/ja-jp/manage-users/access-control/configure-core-rbac/roles/create-roles)。作成したロールの名前は必ず、[あらかじめ定義されたDAEロール](/docs/ja-jp/customize/extensions/delegated-admin#assign-roles-to-users)と一致しなければなりません。 2. Authorization Core（認可コア）機能セットを使用して、[作成したDAEロールを適切なユーザーに割り当てます](/docs/ja-jp/manage-users/access-control/configure-core-rbac/rbac-users/assign-roles-to-users)。 3. ユーザーのロールをIDトークンにあるDAEの名前空間に追加します。これを行うには、[以下のルールを作成します](/docs/ja-jp/customize/rules/create-rules)。`CLIENT_ID`プレースホルダー値をアプリケーションのクライアントIDに置き換えることを忘れないでください。 ```javascript lines theme={null} function (user, context, callback) { if (context.clientID === 'CLIENT_ID') { const namespace = 'https://example.com/auth0-delegated-admin'; context.idToken[namespace] = { roles: (context.authorization || {}).roles }; } callback(null, user, context); } ``` Auth0は、プロファイル情報を[OpenID Connect（OIDC）仕様](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)で定義されている構造化クレーム形式で返します。つまり、IDトークンまたはアクセストークンに追加するカスタムクレームは、衝突を避けるために[ガイドラインと制限に従わなければなりません](/docs/ja-jp/secure/tokens/json-web-tokens/create-custom-claims)。