質問: IdentityServer 4とAspNetIdentityを使用してOpenID Connectをセットアップするのはこれが初めてであり、ユーザーデータの保存に関する部分をわかりやすく説明できることを望んでいました。 これまでに読んだことは、ユーザーデータは認証サーバーに接続されている認証データベースに保存する必要があるということですが、リソースサーバーに接続されているリソースデータベースにもユーザーデータを保存したいです。 現在、次のようなデータモデルがあります。 ![ここに画像の説明を入力してください](https://i.stack.imgur.com/7PcRw.pngp) ユーザーとイベントの両方のフィールドの多くを省略しましたが、うまくいけば画像が表示されます。 Userテーブル、Eventテーブル、およびHostテーブルがあります。ユーザーはイベントをホストできます。ユーザーとイベント間の多対多の関係は、ホストテーブルを介して行われます。 これはアーキテクチャに関する初歩的な質問ですが、理にかなっていて完全なハックではない良い答えを見つけるのは本当に難しいです。これまでに、さまざまな人々からの次のソリューションについて読んでいます。 1. すべてのユーザーデータを認証データベースのみに保存し、リソースサーバーが認証サーバーからデータを取得できるように、認証サーバーにAPIを設定します。 2. 他の誰かが、ユーザーの市や国などの非認証関連データを認証データベースに保存すべきでないと言います。代わりに、認証関連データを認証サーバーのみに保持し、ユーザー関連データをリソースDBに保持します。これは、2つのユーザーレコードを同期する必要があるように聞こえますか?悪い考えのようですね。 3. ユーザー、ホスト、イベントの間に必要な関係を構築できるように、リソースサーバーと認証サーバーを1つのアプリケーションにします。しかし、これはOpenID Connectを使用する目的全体を無効にしているようです。 では、ここでの標準アーキテクチャは何ですか?または、すべてに適合するサイズがない場合、このユーザーデータをどのように保存しますか?
回答: 懸念の分離と単一の責任を念頭に置いて: *ユーザーテーブルは1つだけではありません。*テーブル内のフィールドは、コンテキスト内でのみ意味を持ちます。 ユーザーはログインするためのGoogleアカウントを持つことができますが、従業員に連絡できるアカウントではないビジネスの場合です。コンテキストの一部ではないレポートに情報を表示するのはどうですか?アイデンティティコンテキストに都市を格納するとします。次に、その情報をレポートにどのように表示しますか?ビジネスコンテキストの情報が必要になります。 また、IDコンテキストが情報を保存するのに適した場所であるかどうかも考慮してください。ユーザーが制御しているためです。ユーザーが情報の使用に同意しない場合、または単にアカウントを削除した場合はどうなりますか?また、データを同期するときに使用する戦略は何ですか? コンテキストの共有は簡単です。 IDはIdentityServerの責任であり、IDコンテキストにはIDに関する情報のみを含める必要があり、IdentityServerのみがアクセスできます。 IdentityServerは1つのアプリにバインドされていないことに注意してください。 *各コンテキストにユーザーテーブルが必要です。*情報は冗長に見えるかもしれませんが、実際にはそうではありません。なぜなら、それは別のコンテキストの一部だからです。 googleなどのプロバイダーを使用してログインするときのように。次に、ユーザーのローカルコピーがIDコンテキストに作成されます。 ただし、ビジネスコンテキストではUserと呼ばないでください。ビジネスコンテキスト内にはユーザーがいないためです。ほとんどの場合、彼らは従業員、顧客などです。誰がログインできますが、必ずしもそうではありません。また、ビジネスに知られていない(アイデンティティ)ユーザーを持つことも可能です(たとえば、複数のアプリの場合)。 IdentityServerは、ユーザーを認証する権限です。承認は複数のレベルで実装できます。別の許可サーバー( policyserverなど )を作成できます。または、下位レベル( リソースベース )。「person」テーブル内にユーザーが存在するということは、ユーザーがリソースにアクセスできることを意味します。 別のコンテキストの最良の部分は、コンテキスト内で、他のコンテキストに干渉することなく、テーブル間のリレーションを作成できることです。必要に応じて、別のoidcプロバイダーに簡単に切り替えることができます。しかし、一度コンテキストをミックスし始めると、戻る方法はありません。 oidcで非常に役立つ1つのことは、 `sub`クレームです。 `sub`クレームでユーザーを検索し、ビジネスコンテキストにローカルIDを使用するだけです。 IDコンテキストのフィールド`city`および`country`について:認証には複数のレベルがあるため、このコンテキストで実際に情報が必要になる場合があります。ただし、別のコンテキストで情報が必要な場合(レポートに表示する場合など)、そこに追加する必要があります(同様に)。