Web Api Core中的社交身份验证 [英] Social authentication in Web Api Core

问题描述

ASP.NET Core集成了对Google, Facebook and Twitter身份验证的支持.这篇 msdn文章涵盖得很好.

ASP.NET Core has integrated support for Google, Facebook and Twitter authentication. This msdn article covers it pretty well.

但是似乎它仅适用于MVC，但是对于Web Api，您必须自己实现很多东西.多亏了Openiddict，我才为我的项目成功地做到了这一点，但仍然感觉我不得不写相当低级的代码，而这应该是框架的一部分.

But it seems like it works only for MVC but for Web Api you have to implement a lot of stuff on your own. Thanks to Openiddict I managed to do it for my project but it still feels like I have to write quite low-level code that should be a part of framework.

最好在Web Api中进行类似app.UseGoogleAuthentication的简单调用.所以我的问题是，为什么现在不支持它们(是否存在任何体系结构问题)，并且最终有计划支持它?

It would be nice to have simple calls like app.UseGoogleAuthentication in Web Api. 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?

推荐答案

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

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.

这篇关于Web Api Core中的社交身份验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！