メインコンテンツへスキップ
ユーザー情報は、多くの場合、複数のオンラインリソースに分散して保存されています。ユーザーは、Flickr のようなサービスに写真をアップロードして保存したり、Dropbox にデジタルファイルを保管したり、Google Calendar や Facebook に連絡先や予定を保存したりすることがあります。 新しいアプリケーションでは、こうしたオンラインリソースにすでに存在する情報を利用したい場合がよくあります。そのためには、アプリケーションはユーザーに代わってその情報にアクセスするための認可を求める必要があります。スコープは、アプリケーションがユーザーに代わって実行できる操作の範囲を定義します。

​
スコープの使い方

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

​
ベストプラクティス

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

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

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

​
詳細