Skip to main content
ユーザーに関するさまざまな情報は、多くの場合、複数のオンラインリソースに分散して保存されています。たとえば、Flickr のようなサービスに写真をアップロードして保存したり、Dropbox にデジタルファイルを保管したり、Google Calendar や Facebook に連絡先やイベントを保存したりします。 新しいアプリケーションでは、こうしたオンラインリソース上にすでにある情報を利用したい場合がよくあります。そのためには、アプリケーションがユーザーに代わってその情報にアクセスするための認可をリクエストする必要があります。スコープは、アプリケーションがユーザーに代わって実行できる具体的な操作を定義します。

​
スコープの使い方

アプリが を通じてリソースへのアクセス許可をリクエストする際は、必要なアクセス権を指定するために scope パラメーターを使用します。また、認可サーバーも、実際に付与されたアクセス権を返す際に scope パラメーターを使用します (付与されたアクセス権がリクエスト内容と異なる場合) 。 一般的に、スコープには次の 3 つの使い方があります。
  • アプリケーションから、ユーザーの本人確認を行い、メールアドレスやプロフィール画像などの基本的なプロファイル情報を取得する方法です。このシナリオで使用できるスコープには、 Connect (OIDC) プロトコルで定義されているものが含まれます。詳しくは、OpenID Connect スコープ を参照してください。
  • API で、アクセス制御を実装する方法です。この場合は、API 用のカスタムスコープを定義し、呼び出し元のアプリケーションが利用できるようにそれらのスコープを識別できるようにする必要があります。詳しくは、API スコープ を参照してください。
  • アプリケーションから、独自のカスタムスコープを実装している API を呼び出す方法です。この場合は、呼び出す API にどのカスタムスコープが定義されているかを把握しておく必要があります。アプリケーションからカスタム API を呼び出す例については、スコープとクレームのユースケース例 を参照してください。

​
ベストプラクティス

ユースケースを理解し、できるだけ制限の厳しいスコープを選択してください。 スコープを要求する場合は、アプリケーションが動作するのに十分なアクセス権を求めつつ、本当に必要なものだけを要求するようにしてください。必要なのはユーザーの本人確認でしょうか。それとも、ユーザーのデータを操作する許可を求めているのでしょうか。ユーザーの Facebook プロファイル情報を取り込むことと、ユーザーのウォールに投稿することには大きな違いがあります。必要なものだけを要求すれば、必要な場合にユーザーの同意を得られる可能性が高くなります。ユーザーは、範囲が限定され、内容が明確なスコープであればアクセスを許可しやすいからです。 同様に、API 用のカスタムスコープを作成する際は、アプリケーションにどの程度細かいアクセス制御が必要になる可能性があるかを考慮し、それに応じて設計してください。

​
要求されたスコープと付与されたスコープ

場合によっては、要求されているアクセスについて、ユーザーが同意を求められることがあります。通常、返されるスコープは要求されたものと同じですが、ユーザーは付与するスコープを編集できるため (最初の同意時と、リソースによってはその後も) 、アプリケーションが要求したよりも少ないアクセス権だけを付与することがあります。 アプリケーション開発者は、この可能性を考慮し、こうしたケースにアプリケーション内で対処できるようにしておく必要があります。たとえば、利用できる機能が一部制限されることをユーザーに警告できます。また、追加の権限を求めるために、ユーザーをに再度進ませることもできます。ただし、繰り返しになりますが、同意を求められたとき、ユーザーはいつでも拒否できます。 Auth0 ではデフォルトで、ファーストパーティアプリケーションに対するユーザー同意はスキップされます。これは、そのアプリケーションが呼び出す API と同じ Auth0 ドメインの下で登録されているアプリケーションです。ただし、Auth0 では、ファーストパーティアプリケーションでもユーザー同意を必須にするよう API を設定できます。外部アプリケーションであるサードパーティアプリケーションでは、ユーザー同意が必要です。

​
さらに詳しく