所以我的问题是，为什么现在不支持它们(是否存在任何体系结构问题)，并且最终有计划支持它?

So my question is why they are not supported at the moment (are there any architectural problems) and are there plans to support it eventually?

虽然我不能代表ASP.NET团队谈论为什么他们不希望从事身份提供者项目(我 s ，但这会直接与Microsoft的商业报价Azure AD发生冲突)和Azure B2C)，我可以告诉你为什么直接接受未设计为应用程序使用的第三方令牌不是一个好主意，因此，为什么OWIN从未支持它/Katana和ASP.NET Core.

While I can't speak for the ASP.NET team about why they don't want to work on an identity provider project (I guess it would directly conflict with Microsoft's commercial offers, Azure AD and Azure B2C), I can tell you why directly accepting third-party tokens that were not designed to be used by your app is not a good idea, and thus, why it has never been supported in OWIN/Katana and ASP.NET Core.

原因实际上很简单:实施起来极具风险，因为它容易受到低估的攻击:混乱的副手攻击.关于此攻击如何工作的详细信息，请参见这样的答案(注意:它提到了隐式流程，但是当 confused agent of 是API本身时，它实际上适用于任何流程):

The reason is actually simple: it's extremely risky to implement, as it's prone to an underestimated class of attack: the confused deputy attack. Details about how this attack works can be found in this great SO answer (note: it mentions the implicit flow, but it actually works with any flow when the confused deputy is the API itself):

1. 爱丽丝使用Google登录FileStore.
2. 在身份验证过程之后，FileStore为Alice创建一个帐户，并将其与Google用户ID XYZ关联.
3. Alice将一些文件上传到她的FileStore帐户.到目前为止，一切都很好.
4. 后来，爱丽丝(Alice)登录了EvilApp，该EvilApp提供了看起来很有趣的游戏.
5. 结果，EvilApp获得了与Google用户ID XYZ关联的访问令牌.
6. EvilApp的所有者现在可以为FileStore构造重定向URI，插入为Alice的Google帐户颁发的访问令牌.
7. 攻击者连接到FileStore，后者将获取访问令牌并与Google核对以了解其用途. Google会说它是用户XYZ.
8. FileStore将使攻击者可以访问Alice的文件，因为攻击者具有针对Google用户XYZ的访问令牌.

1. Alice signs into FileStore using Google.
2. After the auth process, FileStore creates an account for Alice and associates it with Google user ID XYZ.
3. Alice uploads some files to her FileStore account. So far everything is fine.
4. Later, Alice signs into EvilApp, which offers games that look kind of fun.
5. As a result, EvilApp gains an access token that is associated with Google user ID XYZ.
6. The owner of EvilApp can now construct the redirect URI for FileStore, inserting the access token it was issued for Alice's Google account.
7. The attacker connects to FileStore, which will take the access token and check with Google to see what user it is for. Google will say that it is user XYZ.
8. FileStore will give the attacker access to Alice's files because the attacker has an access token for Google user XYZ.

FileStore的错误是未与Google确认所获得的访问令牌是否确实发给了FileStore；该令牌确实已发行给EvilApp.

FileStore's mistake was not verifying with Google that the access token it was given was truly issued to FileStore; the token was really issued to EvilApp.