実際のシナリオでIDサーバー認証を実装する
IdentityServer 3がどのように機能するかを調査していますが、完全に理解する必要があります。
一般的なコンセプトは私には明らかですが、実際のプロジェクトでこれを実装する方法はわかりません。
これは私の場合に実装しようとしている基本的な例です： link
Web APIプロジェクトがあり、任意のクライアント（MVC、WPF、電話など）からAPIメソッドを呼び出したいので、すべてのクライアントに適した実装が必要です。
私がよく理解している場合（そしておそらく完全に理解していない場合）、3つのプロジェクトが必要です。
- クライアント
- API
- IdentityServerをホストするプロジェクト
そして、すべてのプロジェクトは画像のようなものが必要でした： 
画像の手順：
- トークンを取得
- トークンを返す
- APIを呼び出す
- トークンに問題がないか確認します
- トークンがデータを返すよりも良い場合は、エラーを表示します
私の質問は：
- これがどのように機能するかについての私の考えは大丈夫ですか？
- どこで間違いをしましたか？
- この例は私の場合に十分ですか？重要なものが欠けていますか？
- IdentityServerをホストするプロジェクトを作成する必要がありますか、それともサンプルコードだけが必要ですか？
- IdentityServer Hostプロジェクトは、APIとクライアント（例のように）と通信するコンソールアプリケーションである必要がありますか、それとも実際にはこれは別の方法で行われますか？
- ホストIDサーバーがクライアントとユーザーを認識していることを投影する必要がありますか？
- ホストアイデンティティサーバープロジェクト以外のプロジェクトは、クライアントとユーザーを認識している必要がありますか？
- 暗黙的フローとハイブリッドフローの違いは何ですか？私の場合に何が必要ですか？なぜですか？
- 独自のログインビューを作成するにはどうすればよいですか？ Webクライアントを使用する場合はログイン用のHTMLページが必要ですが、WPFを使用する場合はWPFログインビューが必要ですが、モバイルクライアントのビューも異なります。
編集：私は Resource Owner flow が必要だと思います。私はそのリソースがユーザーがユーザー名とパスワードを入力する場所を表示すると思います。
Identity Serverが承認サーバーとして機能し、クライアントとWeb APIが分離されているため、基本的なフローは適切です。
Identity Serverを独自のプロジェクトでホストして、セキュリティ上の問題を引き起こす可能性のある他のロジックから切り離してください。ホストする方法は、あなたとあなたのユースケース次第です。通常は、IISサーバー上のASP.NETプロジェクト内でホストされています。
Identity Serverは、クライアントとユーザーを認証するためにそれらを認識する必要があります。 IDストア（ユーザー）を認識する必要のある他の唯一のプロジェクトは、管理、ユーザー登録などに関係するアプリケーションです。クライアントストアは、Identity Serverでのみ使用されます。
Identity Serverテンプレートを使用するか、独自のViewServiceを導入することで、ビューを変更できます。詳細はドキュメントを参照してください： https://identityserver.github.io/Documentation/docsv2/advanced/customizingViews.html
フローに関して、リソース所有者フローはOAuthのみなので、認証（ログインページ）はなく、承認（サーバーからサーバー）のみになります。