-
Notifications
You must be signed in to change notification settings - Fork 599
Authorize(Github) may return a Facebook user #859
Comments
Just to be clear, prior to returning the SignInScheme Identity, Authenticate on any remote provider would have thrown an exception? So this is a new behavior we are defining? Seems like we can just make it clear in the doc comments what this behavior does (it really is calling Authenticate("SignInScheme") |
It used to cause an infinite loop because Authenticate(Github) always returned null, so a new Challenge(Github) would be issued. We broke the infinite loop by having it return the current SignInScheme user. |
Okay yeah so that infinite loop behavior is the interaction between MVC's AuthorizeFilter and RemoteHandlers always returning null. I don't think the new behavior will be too confusing since if they are sharing external cookies, they will likely not be calling the shared scheme Facebook/Google, but rather something like "External", so it would be more that you are getting the "External" identity when asking for either "Facebook"/"Google" which makes sense to me if you've configured them this way |
We're going to start by documenting this and see if users run into issues. Other options:
|
Would it be possible to store external provider cookies by provider name eg Identity.Google Or would that require too much heavy lifting. |
We can store the provider information directly in the cookie / auth properties. We don't need a separate cookie. |
https://github.com/aspnet/Security/pull/823/files/59fc691f4152e6d5017176c0b700ee9834640481#r64260972
For remote providers we implemented Authenticate to delegate to the current SignInScheme provider. However, we opted not to verify that the current identity provided by the SignInScheme provider was actually produced by the given middleware. E.g. When you have OAuth set up for Facebook and Github, they share an auth cookie, so when you Authorize(Github), if Facebook is already logged in, you get Facebook. This may be very confusing to users if there are portions of their application that require credentials from different providers. To work around this they would have to sign-out of the exiting provider, redirect, and then sign-in with the new provider.
The text was updated successfully, but these errors were encountered: