私は現在、以下のサービスマイクロサーバアーキテクチャでは、認証サーバとユーザサービスを組み合わせるべきですか？
ユーザーが資格情報を認証サーバーに送信すると、認証サーバーはそれらが正しいことを確認してからアクセストークンを返す必要があります。
私の質問はとても資格情報を検索すると、単純なデータベース呼び出しである私は、ユーザーのサービスで認証サーバーを組み合わせるべきである、または私はそれらは別個のアプリケーションとして維持し、それらに同じ共有データベースへの両方のポイントを持っている必要がありますか？よりよい選択肢がありますか？
私が通常行っていることは、それらを分けておくことです。アカウント情報（名、姓、連絡先、所属、性別など）は、認証/承認とは関係ありません。また、アカウントには複数の認証方法（OAuth、uname-pass、プライベートキー）を使用できますが、実際にアカウントデータには関係しません。だから、私はそれらを別々のエンティティとして扱います。私は、認証とアカウントのデータは同じように見えますが、責任が非常に異なる2つの非常に異なるものを表しているので、それらを別々にしています。 1人のユーザーが他のユーザーの名字を見なければならない場合は、他のユーザーの資格情報をデータベースから取得したくない場合があります（多くは間違っている可能性があります）。
あなたがSpring SecurityのUserServiceを考えているのであれば、Auth serverと一緒に行きます。
セキュリティの観点からは、真実の単一点（認証サーバー）を持ち、問題を1か所で解決できることが大きな利点です。
いずれにせよ、IMHO、account、およびauthはいくつかのプロパティを共有できますが、それらは2つの異なるものです。
これが役に立ちます。
oauthはアイデンティティ管理とは関係なくオーソリゼーションの委任に関係します。
oauth2には、認可サーバーがリソースサーバーの1つのマイクロサービスの一部である必要があるかどうかを現在尋ねている4つの役割（リソースサーバー、リソース所有者、クライアントおよび認可サーバー）があります。
ユーザー名を正しく指定した場合、oauth2用語のリソース所有者ロールに対応します。oauth2フロー（例：client_credentials）は、クライアントが直接リソースサーバーへのアクセスを許可し、ユーザーは存在しませんいずれにせよ暗示される。