所以我的问题是为什么目前不支持它们(是否存在任何架构问题)并且是否有计划最终支持它?
虽然我不能代表 ASP.NET 团队谈论他们为什么不想从事身份提供者项目(我猜这会与微软的商业产品 Azure AD 和 Azure B2C 直接冲突),但我可以告诉你为什么直接接受不是为您的应用程序设计的第三方令牌不是一个好主意,因此,为什么 OWIN/Katana 和 ASP.NET Core 从未支持它。
原因其实很简单:实施起来风险极大,因为它容易出现被低估的一类攻击:混淆副攻击。有关此攻击如何工作的详细信息可以在这个伟大的 SO 答案中找到(注意:它提到了隐式流,但当混淆的代理是 API 本身时,它实际上适用于任何流):
- Alice 使用 Google 登录 FileStore。
- 在身份验证过程之后,FileStore 为 Alice 创建一个帐户并将其与 Google 用户 ID XYZ 相关联。
- Alice 将一些文件上传到她的 FileStore 帐户。到目前为止一切都很好。
- 后来,Alice 登录了 EvilApp,它提供的游戏看起来很有趣。
- 结果,EvilApp 获得了与 Google 用户 ID XYZ 关联的访问令牌。
- EvilApp 的所有者现在可以为 FileStore 构造重定向 URI,插入它为 Alice 的 Google 帐户颁发的访问令牌。
- 攻击者连接到 FileStore,它会获取访问令牌并与 Google 核对以查看它是针对哪个用户的。谷歌会说它是用户 XYZ。
- FileStore 将允许攻击者访问 Alice 的文件,因为攻击者拥有 Google 用户 XYZ 的访问令牌。
FileStore 的错误在于没有向 Google 验证它所提供的访问令牌确实是颁发给 FileStore 的;令牌确实是发给 EvilApp 的。