私たちのアプリケーションは、すでに複数の認可サーバーに委任するクライアントです。要点は、ユーザー アカウントはありますが、資格情報を保存していないということです。ユーザーは Facebook / Google / などから認証され、ローカル アカウントが自動的に作成されます。
現在、このアプリケーションが成長したため、他のアプリケーションが API との統合を望んでいるため、独自の OAuth2 エンドポイントを提供したいと考えています。本格的な OAuth2 サーバーを実装し、一部を Facebook/Google/whatnot に委譲し、それ以外は通常のサーバーとして機能します (独自のアクセス トークン、更新トークンなどを発行します)。それは期待されることですか？このユースケースに固有の標準に何かありますか?
あなたのアプローチは正常です。現在、リソース サーバーを実装し、Google などは承認サーバーです。新しい認可サーバーの実装を計画しています。論理的には、これは同じ物理サーバー上にある場合でも、リソース サーバーとは完全に区別されます。
ただし、認可サーバーは複数の独立したクライアントをサポートすることを目的としているため、実装は比較的複雑です。他のサード パーティ クライアントをサポートしたくない場合は、独自の認証用により単純なメンバーシップ プロバイダー タイプ モデルを選択し、外部認証プロバイダー用の OAuth 部分を保持できます。つまり、アプリケーションにサインイン ページを用意し、ユーザー名とハッシュされた資格情報を DB に保持し、アプリケーション セッションを使用するだけです。メンバーシップ プロバイダーを使用して「ネイティブに」サインインするか、外部のものを使用してサインインするかをユーザーが選択できるようにするための UI を提供します。
多くのサイトがこの二重のアプローチを採用しています (たとえば、StackOverflow 自体 - Facebook または SO アカウントでサインインできます)。本格的な OAuth 2 認可サーバーよりも手間がかかりません。