Web Api Coreのソーシャル認証

Question

ASP.NET Coreには、Google, Facebook and Twitter認証の統合サポートがあります。このmsdn articleはかなりうまくカバーしています。

しかし、それはMVCのためだけに働くようですが、Web Apiのためには、あなた自身で多くのものを実装する必要があります。 Openiddictのおかげで、私は自分のプロジェクトでそれをやっていましたが、フレームワークの一部であるはずのかなり低レベルのコードを書く必要があるような気がします。

のような単純なコールをWeb Apiに入れるとよいでしょう。ですから私の質問は、現時点ではサポートされていない（アーキテクチャ上の問題はありますか？）、それを最終的にサポートする予定がある理由です。

Answer 1

私の質問は、現時点ではサポートされていない（アーキテクチャ上の問題はありますか）と、それを最終的にサポートする予定がある理由です。私は、彼らがアイデンティティプロバイダのプロジェクトで作業したくない理由についてASP.NETチームのために話すことはできませんが

（私はそれが直接、Microsoftの商業的なオファー、AzureのADとアズールと競合するを推測B2C）、私はを直接あなたのアプリで使用するように設計されていないサードパーティのトークンを受け入れることは良い考えではないことを伝えることができるので、OWIN/KatanaとASP.NET Core 。

理由は、実際に簡単です：それは攻撃の過小評価クラスになりやすいですと、それは、を実装することは非常に危険なのです：混乱して副攻撃。グーグルを使ってファイルストアへ

1. アリスの兆候：この攻撃はcan be found in this great SO answer（：それは暗黙の流れに言及したが、混乱し副がAPI自体であるとき、それは実際にどんな流れで動作するノートを）どのように機能するかについての詳細。
2. 認証プロセスの後、FileStoreはAliceのアカウントを作成し、GoogleユーザーID XYZに関連付けます。
3. アリスはファイルを自分のFileStoreアカウントにアップロードします。これまでのところすべてが問題ありません。
4. その後、アリスはEvilAppにサインインします。
5. その結果、EvilAppはGoogleユーザーID XYZに関連付けられたアクセストークンを取得します。
6. EvilAppの所有者は、アリスのGoogleアカウント用に発行されたアクセストークンを挿入してFileStoreのリダイレクトURIを構築できるようになりました。
7. 攻撃者はFileStoreに接続します。FileStoreは、アクセストークンを取得し、Googleでどのユーザーが使用されているかを確認します。 GoogleはそれがユーザーXYZであると言います。
8. 攻撃者がGoogleユーザーXYZのアクセストークンを持っているため、FileStoreは攻撃者にアリスのファイルへのアクセスを許可します。

FileStoreの間違いは、それが与えられたアクセストークンが本当にFileStoreに発行されたということをGoogleと検証していなかったことです。トークンは実際にEvilAppに発行されました。リソースサーバーdoesnの場合：