CODEWITHSUNDEEP
asp.net-mvc-4oauth-2.0facebook-oauth
Tom Schreck
Tom Schreck

Reputation: 5287

ASP.Net MVC 4 OAuthWebSecurity logout

I'm implementing ASP.Net MVC's OAuthWebSecurity for my Internet app. I can successfully authenticate using Facebook, Twitter, Google, and Yahoo. The first time I authenticate with each of these, I'm sent to their respective site to authorize my application. Makes sense.

However, I'm not presented with the provider's authorization screen on subsequent authentication attempts with Facebook, Google, and Yahoo. It seems Twitter asks me every time.

Is this a problem? If a different person uses my computer and uses my app with Facebook authentication will they be authenticated as me? How are oAuth results cached? How do you clear them?

Thanks.

Upvotes: 2

Views: 1829

Answers (3)

Ostati
Ostati

Reputation: 4741

Each provider must include the "SignOutUri" in the response i.e. ExtraData.. How difficult would that be?

Upvotes: 0

acarlon
acarlon

Reputation: 17264

It is actually worse than you describe. Any subsequent user will have access to your user account at the provider (e.g. google/facebook, etc), not just your application.

Did you find any good way of handling this? I have offered some suggestions below, but I hope that there are better options available / in the pipeline.

What you have described is a real problem and a bit of a hole in the whole system from my perspective. Using asp.net MVC, as you indicate you are, WebSecurity.Logout() does not log the user out of the provider.

I'll indicate why I think it is a problem after I have provided a few options. The crux of both solutions is that if the user logs out of their provider, then they will no longer be able to log into your site without re-authenticating and they will not leave their provider user account open.

  1. Log them off from whatever their provider is. If their provider is facebook then follow the instructions at this answer. If the provider is google, you can redirect to "https://accounts.google.com/Logout". Unfortunately, this is all a bit clunky and will differ between providers.

  2. When the user clicks 'logout' on your site, show a message indicating that they should log off from their provider and then direct to the provider site. For example if the provider is google, then when they click log off, show a message such as 'Please remember to log off from google' and then direct them to www.google.com. This will not actually log them off, but will at least be consistent. This is the approach that I am using until I find something better. It is not ideal as it takes them out of your site, but at least they are not being exposed to big security flaw.

The reason that I think that leaving the user logged into the provider is bad is demonstrated by the following example: -

  1. User is on a public computer.
  2. User opens an EmergencyIceCream (fictitious) site.
  3. On the EmergencyIceCream site, User chooses to log in using a provider (e.g. google/facebook).
  4. User has ordered their emergency icecream and clicks log out.
  5. User is taken back to the EmergencyIceCream home page.
  6. User is happy that they have logged out.
  7. BadUser comes to the computer and can't believe their luck that when they go to the provider's site (e.g. google/facebook) and they have access to and control over User's account as well as any applications tied to User's account (including EmergencyIceCream).

I think that there should be an option to log out of the social provider as well. I am not sure if this is something that could be done under the hood in OAuthWebSecurity or needs to change in the open-id/oauth implementation. I don't think it is a very good option to have code to log out of each provider individually. I don't agree that this is how oauth works and that we should live with it or use our own authentication and authorization. As a consumer of the OAuthWebSecurity feature to simplify the login process for my app, I now have more work to do and weakened security for the user. Also, the fact that logging out of the provider solves the issue indicates that there is a way to solve this.

Upvotes: 3

Eamon
Eamon

Reputation: 246

A token revoke will mean your users will have to give your app permission to share data each time; they shouldn’t have to keep giving permission.

With Outh you’re outsourcing the login process to FB etc, if you are logged in to FB then you are also logged in to you app (aka single sign on)

…go to your fb account and log off then launch your app again, it should now prompt and let you log in via another FB account if need be.

If you want to remain signed into FB as you but sign in to your app as somebody else then OAuthWebSecurity was probably not your best design choice.

Upvotes: 0

Related Questions