3 ms·

Actually, the issue is that the site in question implemented it wrongly, and the users have the correct mental model. On my site, the users in red would actuall

by relix 13y ago

Actually, the issue is that the site in question implemented it wrongly, and the users have the correct mental model. On my site, the users in red would actually be correct, i.e. logging out of my site would log you out of Facebook. This is also the more logical, consistent and secure approach, because if the user stays logged in on Facebook even after pressing "log out" on my app, just pressing the "connect on facebook" button again would log the user in without asking for a password. This is not secure. It's quite simple: when a user is signed out on your app, use the javascript SDK to sign-out the user from Facebook as well. You can easily do this by loading the SDK, subscribing to the status-event, and if (user is not signed in in my application) && (facebook SDK says user is signed in to facebook), then call FB.logout(). This is a workaround though, you should just combine both when pressing the "sign-out" button of your website - i.e. send an ajax request to the sign-out page, send an FB.logout request to facebook, redirect user when complete. That has the added advantage that any time a user visits your page, and the client-side SDK tells you the user is connected through Facebook, you can automatically sign-in that user. I've just completed going through the API and everything so I have a pretty good grasp of things right now, I should write a blogpost about how to properly implement Facebook sign-in, because Facebook is traditionally quite lacking on documentation, and definitely doesn't give a clear view of best practices.

bigiain 13y ago
That's also potentially problematic though. I'm not a regular Facebook user, but re-cast in terms of Gmail - if your site logged me out of Gmail every time I logged out of your site, I'd get quite annoyed (and probably quickly stop using your site). Perhaps if your site can detect at login time whether I was already logged in to the site providing the OAuth service (maybe you could use time-to-authenticate, if there's nothing in the API to tell you?) - and only call OAuth-providor.logout() if you knew your site/login triggered the original OAuth site's login - leaving the Facebook (or Gmail) login session active if it was already there before I used it to log in to your site.
- relix 13y ago
  That was how I was planning on doing it at first, indeed! But after giving it some thought that still doesn't make sense. Basically if you sign in using Facebook connect, your accounts are linked, and the third party site should be thought of as an extension of Facebook: If you're signed in in Facebook, then you're signed in to all the apps you've "connected" with. If you go to the site of an app you're connected with, the client-side SDK will alert the app within 2 seconds that you're signed in and connected, and could reasonably redirect you to the signed-in version of their site. I think it comes down to personal preference, and if you're sharing your PC with people you trust, but a sign-out button is meaningless if "signing in" afterwards is possible without any confirmation. The only reason why you would have a sign-out button that signs you out of the third party site, and not out of Facebook, if is someone else wants to use your PC to sign-in on the third party site, without Facebook. That's such a narrow use-case though that I don't think it's worth it to mess up the user's model of security.

by relix 13y ago

bigiain 13y ago

That's also potentially problematic though. I'm not a regular Facebook user, but re-cast in terms of Gmail - if your site logged me out of Gmail every time I logged out of your site, I'd get quite annoyed (and probably quickly stop using your site). Perhaps if your site can detect at login time whether I was already logged in to the site providing the OAuth service (maybe you could use time-to-authenticate, if there's nothing in the API to tell you?) - and only call OAuth-providor.logout() if you knew your site/login triggered the original OAuth site's login - leaving the Facebook (or Gmail) login session active if it was already there before I used it to log in to your site.

relix 13y ago
That was how I was planning on doing it at first, indeed! But after giving it some thought that still doesn't make sense. Basically if you sign in using Facebook connect, your accounts are linked, and the third party site should be thought of as an extension of Facebook: If you're signed in in Facebook, then you're signed in to all the apps you've "connected" with. If you go to the site of an app you're connected with, the client-side SDK will alert the app within 2 seconds that you're signed in and connected, and could reasonably redirect you to the signed-in version of their site. I think it comes down to personal preference, and if you're sharing your PC with people you trust, but a sign-out button is meaningless if "signing in" afterwards is possible without any confirmation. The only reason why you would have a sign-out button that signs you out of the third party site, and not out of Facebook, if is someone else wants to use your PC to sign-in on the third party site, without Facebook. That's such a narrow use-case though that I don't think it's worth it to mess up the user's model of security.