REST API Oauth 2-どの付与タイプを使用しますか？
基本的に、現在のフロントエンドWebアプリケーションからいくつかの行を挿入するアプリケーションがあります。
ユーザーがデータの挿入を許可されているかどうかをサービス層が確認/検証する前のすべての呼び出し（これが、以下に概説する現在のアプローチで立ち往生しているところです）。
REST APIを作成する必要があります。これにより、他のサードパーティのユーザー/開発者（開発者Aとしましょう）がHTTP呼び出しを介してデータを自動的に挿入できるようになります。
上記のシナリオには2つのシナリオがあります。
ユーザーに代わってデータを挿入する-開発者Aシステムのユーザーは何かを行います。次に、開発者AはHTTP RESTエンドポイントを作成して、システムにデータを挿入します。
システムに代わってデータを挿入する-開発者Aは、ユーザーの操作なしでシステムに直接データを挿入したいと考えています（開発者Aサイトでユーザーの操作がないバッチアップロードデータのように）。
REST APIを使用してOauth 2.0を作成し、Authorisation CodeとClient Credentialsの許可タイプを許可しています。
Authorisation Codeは、開発者Aが認証と承認のためにユーザーをサイトにリダイレクトする最初のシナリオを解決するため、アクセストークンを作成するときに、ユーザーとアクセストークン（後で使用するユーザーを確立するために使用）間のリンクを維持しますトークンを作成し、ユーザーがデータの挿入を許可されているかどうかを確認します）。
ここで、2番目のシナリオでは、Client Credentialsを使用しています。開発者Aは、ユーザーの操作なしですぐにアクセストークンを取得できます。
したがって、このシナリオでは、コードがこのREST呼び出しからの呼び出しを検証しようとすると、特定のユーザーのアクセストークンが作成されないため、基本的に失敗します。
この問題をどのように解決すればよいですか？間違った方向に進んでいますか？
検証ロジックをリファクタリングする必要がありますか（クライアント資格情報によるアクセストークンは信頼できるクライアントのみが取得できるため、検証を無視するには）？または、クライアント資格情報のアクセストークンに関連付けるダミー/匿名ユーザーを作成しますか？
UPDATE：
もう少し明確にして、私のさらなるアプローチ。
上記の検証は、ユーザー名/パスワードの検証ではなく、ユーザーの権限をチェックするために内部ユーザーIDに依存するカスタムビジネスロジックです。
このユーザーIDは、承認コード付与タイプを使用して承認したユーザーIDとして取得します。
しかし、クライアント資格情報の場合、私のサブジェクトはユーザーではなく、アプリケーションであり、ユーザーIDとは異なります。
私はこれに以下のように取り組むために協力することを考えています：
管理ユーザーがUser1がアプリケーション（クライアントID /シークレットを作成）をシステムに登録してAPIを使用するとします。私のシステムでこのユーザーのIDを他のOauth関連詳細（クライアントID /秘密/アプリ名など）とともにメモします。そのため、開発者がクライアント資格情報を使用すると、アプリケーション（特定のユーザーではない）の場合、データベースをクエリして、アプリケーションを登録したUser1のユーザーIDを取得します。次に、このユーザーIDを使用して、すべてのビジネスロジック検証を続行します（これにより、このユーザーUser1は、管理者ユーザーであるため、システム内のすべてのリソースにアクセスできるためです。
私のこのアプローチについてのあなたの考え/コメントを聞かせてください。
ビジネスロジックは、エンドユーザーがアクション（レコードの挿入など）を実行できる唯一の種類のIDであると想定しています。仮定は誤りであり、2番目の種類のID、つまりクライアントアプリケーションがあることがわかります。私はいくつかのオプションを見ることができます：
クライアントアプリケーション、つまりサービスアカウントを表す偽の/疑似ユーザーを作成します。システムを期待どおりに動作させるために必要な設定をすべてユーザーに提供しますが、実際のユーザーがこの疑似ユーザーとしてログインできないようにし、ユーザーを管理画面から非表示にしてください。次に、このユーザーの詳細をアクセストークンに入れるか、APIにアクセストークンを取得したときにこのユーザーの詳細を調べさせることができます。
ただし、ビジネスロジックがユーザーとクライアントアプリケーションの両方を有効なIDタイプとして認識できるようにすることをお勧めします。少し目を細めてユーザーテーブルの名前を "identities"に変更すると、偽のユーザーや疑似ユーザーを作成した場合と同じようになります。 。ただし、コードやデータベースの構造によっては、コードを更新してユーザーテーブルをそのままにしておく方が簡単な場合があります。
私があなたのフローを理解している場合は、「認証コード」の付与のみを使用して、REST APIを追加できます。これは管理者ユーザーにのみ許可されます（これは構成データに隠されています。公開されていません。つまり、基本的にはこの新しいREST APIを使用できるのは管理者だけです。これは「検証メカニズム」をバイパスするです。