たとえば、Googleの連絡先とGoogleカレンダーが必要な2つの機能があるとします。ユーザの連続した権限付与時にOAuth 2の認証スコープに「スタック」がありますか？
第1の機能が頻繁に使用されているとしましょう。つまり、ユーザーが両方の認証範囲を許可するように要求すると、大幅な低下率が発生します。
連絡先認証スコープがバインドされているユーザーのアクセストークンを保存した場合、後でそのユーザーの追加認証スコープカレンダーを要求するとどうなりますか？カレンダーのスコープの資格情報だけを持つ新しいトークンが返されますか？
LiveConnectでは、既存のスコープに代わるスコープの結果、アンブレラスコープの新しいトークンが作成され、古いトークンは無効になります。
あなたがauthorization_codeまたは暗黙的な認可タイプフローについて話しているとすれば、新しいスコープをユーザーが承認する必要があります。
ユーザーエージェントは、（現在）必要なスコープでAuthorization Serverの認証エンドポイントに送信されます。必要なスコープには、必要なスコープの完全なセット（古いものと新しいもの）が含まれている必要があります。ユーザーは要求されたスコープを見て、それを承認します。 authorization_code付与タイプの場合、これは、スコープに対するユーザの同意を表す新しいアクセストークンと交換される認証コードをもたらす。暗黙的には、URLフラグメント内に新しいアクセストークンが返されます。いずれの場合でも、この新しいアクセストークンは既存のアクセストークンよりも優先されます。
リフレッシュトークンが含まれている場合 - リフレッシュトークンを使用して新しいアクセストークンを要求すると、要求されているスコープを指定することができます。ただし、スコープは元のスコープのサブセットでなければなりません（OAuth 2.0 spec section 6参照）。ユーザーの同意がなければ拡張することはできません（上記フローを前提とします）。