たとえば、2つの機能があるとします。1つはGoogleコンタクトが必要で、もう1つはGoogleカレンダーが必要です。
また、最初の機能が頻繁に使用されているため、ユーザーに両方の認証スコープを承認するように要求すると、大幅なドロップオフ率が発生するとします。
連絡先の認証範囲がバインドされているユーザーのアクセストークンを保存すると、後でそのユーザーの追加の認証範囲カレンダーを要求するとどうなりますか？カレンダスコープのクレデンシャルのみで新しいトークンを取り戻すことはできますか？
LiveConnectによると、既存のスコープに優先するスコープは、アンブレラスコープを持つ新しいトークンになり、古いトークンは無効になります。
authentication_code または暗黙的な付与タイプのフローについて話していると仮定すると、新しいスコープはユーザーによって承認される必要があります。
ユーザー エージェントは、(現在) 必要なスコープと共に、認可サーバーの認可エンドポイントに送信されます。必要なスコープには、必要なスコープの完全なセット (古いものと新しいもの) が含まれている必要があります。ユーザーは要求されたスコープを確認し、それらを承認します。authorization_code グラント タイプの場合、スコープに対するユーザーの同意を表す新しいアクセス トークンと交換される認証コードになります。暗黙的には、URL フラグメントで新しいアクセス トークンを返すだけです。いずれにせよ、この新しいアクセス トークンは既存のものに取って代わります。
リフレッシュ トークンが関係している場合、リフレッシュ トークンを使用して新しいアクセス トークンをリクエストすると、リクエストするスコープを指定できます。ただし、そのスコープは元のスコープのサブセットである必要があります ( OAuth 2.0 仕様のセクション 6を参照)。ユーザーの同意なしにスコープを拡張することはできません (上記のフローを想定)。