アイデンティティ・サーバー4とASP.NETコアID

Question

私が取り組んでいるプロジェクトは、Web API、単一ページの反応アプリケーション、およびモバイル・アプリケーションで構成されています。 Web APIの保護された部分にアクセスするには、各クライアントから、ユーザー名とパスワードを提供する必要があります。私はのIProfileServiceとIResourceOwnerPasswordValidatorの実装を使用するIdentity Server 4認証サーバーを設定しました。これはASP.NET Core Identityを使用しているためです。これにより、Identity Serverは、ASP.NETコアID UserManager,RoleManagerおよびSignInManagersにアクセスし、提供されたユーザー名とパスワードが有効かどうかを判断できます。

私がこれすべてのために使用している認可タイプは、 "ResourceOwnerPassword"タイプです。私は完全に単一ページアプリケーションに認証を統合していませんが、ユーザーのユーザー名とパスワードをIDサーバーに渡すことができ、APIへのリクエストのヘッダーに追加できるトークンが生成されます。

アイデンティティ・サーバーと関連テクノロジーについて私はこれを初めて学んだので、これまでより多くの調査をしました。 ResourceOwnerPassword許可タイプを使用することは望ましくないようです。暗黙の許可タイプを使用する必要があるように見えますが、ユーザー名とパスワードがそのフローにどのように適合するかは完全に理解できません。誰がどのタイプの私が使用すべきであるかについての洞察を持っていますか？私が記述したシステムは、ResourceOwnerPassword付与タイプのみを使用していますか？

Answer 1

リソースの所有者パスワードの交付金型は、これはIdentityServerドキュメントでそれについて書かれています

リソースの所有者パスワードの交付金型はにユーザ名とパスワードを送信することにより、ユーザの 代わってトークンを要求することができますトークン エンドポイント。これはいわゆる "非インタラクティブ"認証であり、通常は です。

この助成金型は便利ですが、一般的な 勧告ではなく、ユーザー認証のための暗黙的またはハイブリッド のようなインタラクティブなフローを使用することで、特定のレガシーまたはファーストパーティの統合の理由 シナリオ、あるかもしれません。

（強調は私です）

他のすべてのフローが関与リダイレクト：ユーザーがウェブサイトのログインをクリックして、代わりにアイデンティティ・サーバーのログインページにリダイレクトされ、彼らはそこに自分の資格情報を入力して、バックにリダイレクトされます元のウェブページ。

これは、他のウェブサイトにログインする場合など、Googleアカウントを使用する場合と同じです。 Googleでは、ユーザー名とパスワードを自分のサイトに入力することを嫌います。なぜなら、ユーザー名とパスワードを盗む可能性があるからです。これは、一般的に、リソース所有者パスワードの付与タイプが推奨されない理由です。 しかし、ファーストパーティの統合を行っている場合（つまり、ウェブサイトが自分のもので、ユーザーが自分のウェブサイトに自分のパスワードを入力することを信じている場合）、問題は何か分かりません。

その他のフロー/許可タイプについては、読んでください（例を見てください）。彼らは確かに彼らの場所を持っており、私はそれらを解雇していませんが、あなたが最初のパーティーの統合をしている場合は何がうまくいくはずです。