いろんなドキュメントを見る限りでOAuthのスコープは良くも悪くもフリーダムに使われていますが、うまく使わないとスコープだらけになります。
したがってスコープを最小限で管理しやすくするために、一番基本の考え方を書いてみましょう。

単一のシステムの中をいかに分けるかをまずはご説明し、複数のシステムが集まった時の話を最後に追加します。

まずはデータの分類から。
社内アプリケーションを例にして解説してみます。

データの分類ポリシーをベースにデータを分類する

弊社の場合ですと、データのセンシティブさは以下のように分類されます。
呼び方はともかく、分類が3分類になること、それぞれに所属するデータの内容はどの会社でもそれほど変わらないようです。

Public
一般に公開される公開情報。
例えば製品のマニュアル、Webページで確認できる会社概要など。

Internal
一般には公開されないが、社内のメンバーやNDAの提携先にだったら公開できる情報。
例えば組織図や各種社内ポリシー、社員の社内向け公開情報 (社用携帯番号、内線番号、メールアドレスなど)。

Restricted (+PII)
知るべき人にアクセスを許可するが、基本は社員であっても非公開となる情報。
顧客情報、社員のプライベートの情報 (PII) など。

これらが一つのエンドポイントに混じると非常に守りにくく使いづらいAPIになります。
したがってまずはこれらが大きく混在しないよう、エンドポイントごとに「これはPublic」「これはInternal」といった具合に分類します。

例えば社員情報データであれば、次のような社内公開プロファイル (Internal) と

/employees/12345

{
   "id": "12345",
   "name": "Sachiko Kijima",
   "extention": "65535",
   "email": "sachiko.kijima@company.com",
   "office": "Tokyo",
   "floor": "8F"
}

プライベートの情報 (Restricted) は

/piis/12345

{
   "id": "12345",
   "address": "東京都千代田区丸の内1-9-1",
   "phone": "080-1234-5678",
   "email": "sachiko.kijima@private.com"
}

エンドポイントを分けます。この例だと /employees と /piis に分けました。

例えば自宅住所や個人のメールアドレスのようなものと、クレジットカードやパスワード、健康状態にまつわるものなど、RestrictedやPIIの中でもそこそこセンシティブなものと高度にセンシティブなものがありますね。
これもやはりエンドポイントを分けましょう。

高度にセンシティブな情報は、例えばクレジットカードであればPCIDSSなど、固有のスタンダードがあるものがあります。守り方のスタンダードが異なるものもエンドポイントを分けましょう。

守り方を検討する

まずはクライアント認証、ユーザーの認証および認可がそれぞれどこで必要になってくるか。

認可とは、見せたらコンプライアンスの問題が起こる情報を隔離すること

認可の使い所についてはこのセクションのタイトルの通り。

認可の話をしている時に、「見せても問題ないデータだけど、紛らわしいから隠したい」という目的が出てくることがあります。
これは認可で実装するものではなく、クエリなどの条件絞り込み機能で実装するものです。

ここからはコンプライアンスの問題が発生しないようにセンシティブな情報を隠すための認可の必要性についてご説明します。

クライアント認証

常に必要。
「登録されたクライアント (APIクライアント)」であるということを確認する必要があります。

例えばAPIプラン (どのシステムのAPIはどのクライアントが使えるか) などによって利用可能なAPI を制限したり、あるいは万が一のアクセス集中があった場合などにクライアントを特定して対処することでバックエンドのAPIを保護することができるためです。
この場合のAPIとは「システム」単位、程度に考えていただければ良いです。
したがってアクセス先のシステムを制限するのはまずはAPIプランとクライアント認証の組み合わせで実施します。

ユーザー認証および認可

ユーザー認証および認可が必要かどうかの観点に立つと、それぞれ以下の通り。

Public
基本的にユーザーの認証は必要ない。
※ データの保護以外の目的、例えば「パーソナライズしたコンテンツを届けたい」などの目的でユーザーの認証が必要になることはある。

Internal
ユーザーの認証は必要だが、「Internalに所属するメンバーなら誰でもアクセス可能」というコンテンツのため、RBAC/ABAC/スコープなどによるアクセスコントロールは特に必要ない。

Restricted
RBAC/ABAC/スコープなどによる認可が必要。

スコープの使い所

個人情報 (PII) を、情報資産が必要となる目的に合わせてグルーピングし、アプリケーションごとに特定のグループだけにアクセスさせたい場合にスコープを使います。

RBACやABACなどは情報資産のアクセスコントロールを「人」に応じて制御するやり方でしたが、スコープは情報資産のアクセスコントロールを「アプリケーション (OAuthのクライアント)」に応じて実施する方法です。

たとえば我々がGoogleのソーシャルログオンを使い何かをしようとした時に、アプリケーションごとに以下の必要となる最小限の情報資産にアクセスさせたいと思うことがありますよね。

1. メールアドレスや表示名などの基本情報

2. Gmailの内容

3. アドレス帳の内容

4. ドキュメントの内容

この時に1~4にスコープを設定し、アプリケーションによってどの組み合わせにアクセスして良いかをコントロールできるようにします。

複数システムが単一API Gatewayを使う場合はAPIプランを使う

ここまでは単一システムの中をいかに設計するかの話でした。

APIのカタログ化が最近は要望に入ってくることが増えたため、API Gatewayはプロジェクト単位で置くのではなく、会社標準など広い範囲をカバーするために共有API Gatewayとすることが増えてきました。

この時、社内のアプリケーションだったらどのシステムのエンドポイントも自由に叩いていいよ、という作り方はしません。

どのアプリケーションがどのシステムのAPIにアクセスできるかはAPIプラン を使ってコントロールすることが一般的です。APIプランはソリューションによりアプリケーションプランと呼ばれることもあります。
APIプランには該当システムAPIへのアクセス権申請フローの定義や利用条件、ビジネス観点での流量制御の設定が実施されることが一般的です。