3

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?

SiberianGuy
  • 24,674
  • 56
  • 152
  • 266

1 Answers1

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):

  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'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.

Community
  • 1
  • 1
Kévin Chalet
  • 39,509
  • 7
  • 121
  • 131
  • Honestly, I don't see how this security threat could be reproduced in Authorization Code flow – SiberianGuy Feb 01 '17 at 03:53
  • The OAuth2/OIDC flow used by the client is irrelevant for the resource server (= the API): if the resource server doesn't ensure the access token was issued to a client it fully trusts, then it will be vulnerable to a confused deputy attack, even if you use the code flow to retrieve the access token. – Kévin Chalet Feb 01 '17 at 04:05
  • I posted a separate question on this topic: http://stackoverflow.com/questions/41972322/should-we-check-token-in-case-of-authorization-code-flow – SiberianGuy Feb 01 '17 at 05:13
  • And could you please hint me with any kind of article about "directly accepting tokens" why it was not implemented in Owin. I mean Owin had UseGoogleAuthentication that accepted tokens from Google (kinda directly) and used them for authentication. So your point is we need to use only tokens that were designed by our application? So we shouldn't use OAuth 2 at all? – SiberianGuy Feb 01 '17 at 06:31
  • @Idsa don't mix up access tokens with authorization codes. The social authentication middleware only deal with the second ones as part of the authorization code flow they all implement. These middleware never deal with access tokens and are not made to be used to protect your APIs. – Kévin Chalet Feb 01 '17 at 18:53