認証
ユーザー管理
カスタマイズ
Auth0 AI
プラットフォーム- アプリケーションがユーザーに代わってアクセスできるようにする情報を決定します。
- それらのアクセス レベルをカスタム スコープとして定義します。 (スコープについては、Scopes を参照してください。)
- 呼び出し元のアプリケーションが利用できるよう、これらのスコープを明示します。
APIスコープの使い方
- 呼び出し元のアプリケーションがサードパーティアプリケーション、つまり外部アプリケーションである API の場合。このケースでは、呼び出し元のアプリケーションが、要求されたスコープへのアクセスについてユーザーに認可を求め、ユーザーがその要求を承認または拒否します。
- 呼び出し元のアプリケーションがファーストパーティアプリケーション、つまり呼び出し先 API と同じ Auth0 ドメインに登録されているアプリケーションである API の場合。このケースでは、既定ではユーザーの同意は求められませんが、同意を必須にするよう設定することもできます。
- 呼び出し元のアプリケーションが、サードパーティかファーストパーティかを問わず、バックエンドサービスであり、ユーザーが存在しない API の場合。このケースでは、ユーザーの同意が求められることはありません。
例: サードパーティアプリケーションから呼び出される API
read:balance)、もう 1 つは資金の送金を許可するもの (transfer:funds) です。この API は Auth0 に登録されています。
呼び出し元のアプリケーションは、要求するスコープへのアクセスについてユーザーに認可を求め、ユーザーはその要求を承認または拒否します。アプリは、リクエストに read:balance スコープを含めることでユーザーの残高の参照アクセスを要求したり、リクエストに transfer:funds スコープを含めることで資金を送金するためのアクセスを要求したりできます。また、read:balance と transfer:funds の両方のスコープをリクエストに含めることで、ユーザーの残高の参照と資金の送金の両方へのアクセスを要求することもできます。
このとき、アプリが API を呼び出す際には、ユーザーが自身の情報へのアクセスを認可したことを示し、あわせてユーザーが承認したスコープを示すトークンを含めます。API は承認済みのスコープを尊重し、ユーザーが呼び出し元アプリケーションに対して認可した情報だけを返すようにする必要があります。
例: ファーストパーティアプリケーションから呼び出される API
organizer ロールと participant ロールを作成します。organizer ロールを持つユーザーはイベントを作成および更新する必要があり、participant ロールを持つユーザーはイベントを閲覧し、イベントに登録する必要があります。そのために、この API 用に 4 つのスコープを作成します。1 つはイベントの作成を許可するもの (create:events) 、1 つはイベントの更新を許可するもの (update:events) 、1 つはイベントの読み取り専用アクセスを許可するもの (view:events) 、そして 1 つはイベントへの登録を許可するもの (register:events) です。API とイベントアプリケーションはどちらも Auth0 に登録されており、API ではファーストパーティアプリケーション向けの Allow Skipping User Consent オプションが有効になっています。Authorization Extension をインストールし、organizer ロールを設定して、そのロールに create:events と update:events のスコープを作成し、ユーザー A に割り当てています。また、participant ロールも設定し、そのロールに view:events と register:events のスコープを作成し、ユーザー B に割り当てています。
ユーザー A は呼び出し元アプリケーションで認証され、このアプリケーションは必要なスコープを要求しますが、ファーストパーティアプリケーションであるため、ユーザーの同意は求められません。アプリは create:events、update:events、view:events、register:events の各スコープを任意の組み合わせで要求できますが、ユーザー A は organizer ロールを持つと認識されるため、付与されるのは create:events と update:events のスコープのみです。
このとき、アプリが API を呼び出す際には、認証されたユーザーのロールに関連付けられたスコープについてのみ認可されていることを示すトークンが含まれます。
例: バックエンド サービスから呼び出される API
read:images) 、もう 1 つは画像データの削除アクセスを許可するもの (delete:images) です。API と自動化サービスは Auth0 に登録されており、自動化サービスがこの API のトークンをリクエストできるように許可されています。
呼び出し元の自動化サービスは必要なスコープをリクエストしますが、ユーザーが存在しないため、同意は求められません。サービスは、リクエストに read:images スコープを含めることで画像データへの読み取りアクセスを、delete:images スコープを含めることで削除アクセスを、また read:images と delete:images の両方のスコープを含めることで、読み取りアクセスと削除アクセスの両方をリクエストできます。
このように、自動化サービスが API を呼び出す際には、リクエストしたスコープに対する認可を持っていることを示すトークンが含まれます。