问题
ASP.NET Core has integrated support for Google, Facebook and Twitter authentication. This msdn article covers it pretty well.
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.
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?
回答1:
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?
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.
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):
- Alice signs into FileStore using Google.
- After the auth process, FileStore creates an account for Alice and associates it with Google user ID XYZ.
- Alice uploads some files to her FileStore account. So far everything is fine.
- Later, Alice signs into EvilApp, which offers games that look kind of fun.
- As a result, EvilApp gains an access token that is associated with Google user ID XYZ.
- The owner of EvilApp can now construct the redirect URI for FileStore, inserting the access token it was issued for Alice's Google account.
- 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.
- FileStore will give the attacker access to Alice's files because the attacker has an access token for Google user XYZ.
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.
来源：https://stackoverflow.com/questions/41941493/social-authentication-in-web-api-core