スコープ

スコープの原理とその一般的な使用例を説明します。

ユーザー情報は多くの場合、いくつものオンラインソースにわたってばらばらに保存されています。たとえば、あるユーザーが、写真をFlickrのようなサービスにアップロードして保存し、デジタルファイルはDropboxに、連絡先やイベントはGoogleカレンダーやFacebookに保存しているというように。

多くの場合、新しいアプリケーションは、オンラインリソースですでに作成されている情報を利用しようとします。そのためには、アプリケーションはユーザーに代わってこの情報にアクセスするための承認を求める必要があります。スコープは、アプリケーションがユーザーに代わって実行することができる特定のアクションを定義します。

​

スコープの使用方法

アプリが認可サーバー経由でリソースへのアクセス許可を要求する場合、そのアプリはscopeパラメーターを使用して必要なアクセスを指定し、認可サーバーはscopeパラメーターを使用して、（付与されたアクセスが要求と異なる場合）実際に付与されたアクセスで応答します。

一般的に、スコープの使用方法には3種類あります。

• アプリケーションから、ユーザーのIDを確認して、ユーザーに関する基本的なプロファイル情報（メールアドレスや写真など）を取得するために使用する。このシナリオで使用できるスコープには、OpenID Connect（OIDC）プロトコルによって実装されたスコープが含まれます。詳細については、「OpenID Connectスコープ」をお読みください。
• APIで、アクセス制御を実装する。この場合は、APIのカスタムスコープを定義して、それらのスコープを識別し、呼び出し元のアプリケーションがそれらを使用できるようにする必要があります。詳細については、「APIスコープ」をお読みください。
• アプリケーションから、独自のカスタムスコープを実装したAPIを呼び出す。この場合、呼び出しているAPIにどのカスタムスコープが定義されているのかを知っている必要があります。アプリケーションからのカスタムAPI呼び出しの例は、「ユースケースの例：スコープとクレーム

​

ベストプラクティス

自身のユースケースを理解し、できる限り最も制限されたスコープを選択します。

スコープを要求する場合は、アプリケーションが機能するために必要最低限のアクセスだけを求めるようにしてください。ユーザーIDを確立しようとしているのか、それとも、ユーザーデータの操作を許可するようにユーザーに求めているのか。ユーザーのFacebookプロファイル情報をインポートすることと、この情報を投稿することには、大きな違いがあります。限定され、明確に特定されたスコープのアクセスの方がユーザーが許可する確率が高いため、必要なアクセスのみを求めることで、必要な場面で確実に同意を得られる可能性が高まります。

同様に、APIのカスタムスコープを作成する際には、アプリケーションがどのレベルのアクセスを必要とするのかをきめ細かく考慮し、それに応じて設計してください。

​

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

場合によってはユーザーが要求されたアクセスに同意できます。通常は、要求されたスコープと同じスコープが返されますが、ユーザーは認めたスコープを（リソースによっては、最初の同意時と同意後の両方に）編集することができるため、アプリが要求したよりも少ないアクセスを付与することがあります。

アプリケーションの開発者はこの可能性を考慮して、このような場合にアプリ内で対処する必要があります。たとえば、機能性が制限されることをアプリがユーザーに警告することができます。あるいは、ユーザーを認可フローに戻して、追加の許可を求めることも可能です。しかし、この場合も、同意を求められたユーザーには拒否する権限があります。

Auth0ではデフォルトで、呼び出すAPIと同じAuth0ドメインに登録されているファーストパーティアプリケーションに対するユーザーの同意をスキップしますが、ファーストパーティアプリケーションでもユーザーの同意を必須にするよう、APIを構成することが可能です。外部アプリケーションであるサードパーティアプリケーションについては、ユーザーの同意が必須です。

​

もっと詳しく

• OpenID Connectのスコープ
• APIスコープ
• 「サンプルユースケース」の「スコープとクレーム」
• APIにロールベースのアクセス制御（RBAC）を有効にする