
How People Think Facebook Connect Log‑in and Log‑out Work - cpeterso
http://skinnywhitegirl.com/blog/how-people-think-facebook-connect-login-logout-work/861/
======
jarito
Suggesting that people don't implement multiple auth systems seems short-
sighted. Right now, if I service requires an OAuth login and doesn't actually
use the service it's authing against, I won't use it.

Those of us that use LastPass / 1Password are better off creating independent
accounts with separate passwords rather than centralizing auth to a service
that still basically relies on a single username / password combo.

~~~
webwanderings
I favor using independent accounts, but I never mind using OpenID for
insignificant site access, when more sites were implementing it back then (not
sure why it isn't used much lately).

~~~
snuxoll
> (not sure why it isn't used much lately)

Because it never gained traction and Facebook Connect pretty much killed it
because it doesn't require setup of an additional service. Mind you, Facebook
Connect is a big privacy and security risk, but it's much 'easier' to a user
than setting up OpenID, which is why it won.

I only hope Persona takes off, as it's a much better solution.

~~~
baudehlo
I'd be so much happier implementing Facebook Connect if it gave me an OAuth
scope that didn't include access to your friends list. I don't WANT that
access, so why don't you provide a way for me to not look sneaky to your
users?

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

------
casca
There are 2 issues being raised here. Firstly, Facebook Connect keeps people
logged into Facebook once they've logged out of then authentication consumer
site. From the user's perspective, this may be desirable behavior or not. If
it's their personal desktop and they like to leave themselves logged in to
Facebook then it is. If it's a shared PC at an Internet cafe, probably not. As
part of the Connect API, Facebook could force the authentication consumer site
to ask at the time of logout and to propagate through.

The second issue is that of honeypots and tricking people into providing
credentials. People very seldom check the URL to verify that Facebook or
Twitter are the actual sites that the data is being submitted to. In fact,
they've been trained to do that with services like Mastercard Securecode
usually implemented inside a frame to "arcot.com". This is a much bigger issue
that requires a more imaginative solution.

~~~
robinson-wall
> In fact, they've been trained to do that with services like Mastercard
> Securecode usually implemented inside a frame to "arcot.com".

Even worse, the domain used varies based on your card issuer so there's no
consistency.

------
danso
The problem of users mistakenly entering Facebook credentials into a Facebook-
lookalike login form is definitely a honeypot vulnerability...but what
percentage of these users would also, when asked to register an account on an
entirely new service, would just end up deliberately using their same FB
credentials anyway?

------
antoncohen
Phishing sites are already using the misconception that to log-in with OAuth
(or OpenID, or Facebook Connect) you enter your username and password on the
site. I wrote about it last month after a friend got caught by a phishing
scam. [http://www.antoncohen.com/2013/05/phishing-failure-of-
oauth....](http://www.antoncohen.com/2013/05/phishing-failure-of-oauth.html)

------
nbaum5
Logging out of the service can log you out of Facebook. Depends how Connect is
implemented by the service. See Airbnb as an example.

------
logn
I like the idea others had of just logging you out of facebook too.

The honeypot problem I think is most serious. That can be mitigated by having
a 'challenge' question (e.g., "What is your favorite...") on the SSO managers
such as facebook.

But I think the better solution is that we seriously need to push browsers to
encourage public/private key auth. That we don't have public/private keys
standardized and easy to use is a shame. You could just have a little button
on the browser that asks for a global password. When entered, it then
populates your user-agent with your public key, and a localhost cookie with
your private key. Then this entire mess maybe goes away (but I'm no security
researcher). Maybe we could even then encrypt text boxes easily. That would be
something: right click a text box and select 'PGP' etc.

~~~
bigiain
The problem is - browsers != people. I have 3 browsers open on this machine,
another 3 browsers on the phone in my pocket, four browsers on my iPad, and at
work I keep separate browsers up logged in as either me-at-work or me-
personally. There are also a few machines/browsers I use more-or-less
regularly which aren't "mine" (the meeting room and board room machines, the
girlfiend's laptop…).

While client certs "work" (StartSSL.com's login for example), they fall a fair
way short of "working well across multiple devices". (I'm not even sure if I
could install a client cert on Safari/Chrome/AtomicWeb on iOS if I wanted to.)

Maybe something like Chrome's bookmark/tab syncing could be extended - but I'd
want it to work across Chrome/Firefox/Safari on at least OS X, iOS, Android,
and Linux (and though not important for me, it'd need to work with IE on
various Win versions too, if it's to get any real market penetration). I fear
there's no secure way to make that happen though - who's "cloud" could you
trust with your private key? (Hell, can you even trust Windows with your
private key? I've _still_ not put my real GPG key onto my iPhone because I'm
not convinced that'd be smart…)

------
EGreg
We had to tackle all these kinds of things when building the Q framework. You
can see the result at [http://qbix.com](http://qbix.com) login

Consider this ... what if on a public computer, User X is still logged in with
Facebook, and User Y is logged in with Twitter. In the past, both used
Facebook, Twitter respectively to auth with our service. Now, which user
should be logged in?

Or consider that the user could have logged out of facebook and another user
logged in, while our site was in the background. The user comes back to the
site, and what should we show?

Well, we show this:

[http://cl.ly/image/281I2T2H0W33](http://cl.ly/image/281I2T2H0W33)

[http://cl.ly/image/1C1l0A2n1U3V](http://cl.ly/image/1C1l0A2n1U3V)

Our framework notices stuff like this and just "does the right thing"

~~~
jlgaddis
OT: your blog is being overrun with comment spam.

~~~
EricMuller22
I am regular reader, how are you everybody?

This piece of writing posted at this site is truly nice.

------
sologoub
From a clarity perspective, I really like how Stackoverflow.com (or
StackExchange in general) implements this. When you go to login, it presents
clear icons to choose from, but no form fields. You have to explicitly choose
what you are logging in with.

That said, it does not address the security concerns raised by the article.
The honeypot problem is a pretty prolific one. Same can be done for any
provider that implements it's authentication for 3rd party websites. I'm sure
there is some policing going on from FB/Google/etc, but not sure on the
effectiveness.

------
wisty
> User 4) “Yes. I do not see a separate window for my facebook site so I would
> assume that Buyosphere would have set it up to log me out when I’m done on
> their site. I think I can check to see if I’m logged out by opening facebook
> and seeing if the login boxes come up or if it takes me straight to my FB
> page. I will try it right now….I was wrong it didn’t log me out. I am
> surprised by that. That makes the process of logging off take longer if I
> have to log out of this site and then go to FB to log out of that site
> separately.”

This one has the makings of a programmer.

------
cheald
Two things:

First off, having multiple login systems doesn't necessarily enable you to
honeypot credentials off of people that wouldn't otherwise give them. The
people using Facebook credentials to try to log into a site with Facebook
Connect is probably going to reuse the same username and password when they
register for your site. People who don't understand security are completely
terrible at password reuse discipline.

Second, the solution to this requires a collaborative effort from both the
auth provider and consumer. If I sign into Facebook and check "This is a
public computer", then Facebook should remember that. Then, Facebook should
provide a "finishSession" API call or whatnot, which a site calls when the
user logs out. This lets Facebook determine what to do with the user's
facebook.com cookies - if it's a transient session, wipe them. If it's a
persistent session, don't do anything with them. OAuth clients shouldn't have
to care about the semantics of the Facebook login - just like authentication
is delegated, so should management of the user's session be delegated.

This would preserve user expectations in both cases.

------
incision
I wonder if a metaphor for sign-on services would help disambiguate this?

Would using your "Facebook Card", perhaps signified with a little "ID card"
icon be more comprehensible than the "Connect with..." or "Sign in with..."
which look very much like a sign-in to the source.

I'd expect many people already have a mental model of an ID card or badge
granting "local" access to different things.

~~~
hrabago
There would still be some people that would think "Well I'll just enter my
Facebook credentials to verify my Facebook Card". The problem the site creates
is the login form that has a username input, password input, and a "Connect
with Facebook" button. The user interpreted it as "If I type in my FB
credentials and click this FB button, then FB logs me in."

Instead, they should start with making the user pick "1) Log in using a
Buyosphere account, or 2) Log in using Facebook Connect". It's much less user
friendly, yes, but that's the consequence of having multiple authentication
systems.

------
mcantrell
Doesn't this just reinforce the fact that using a third-party service for
authentication is a bad idea? Most users don't understand it. You app is,
generally, forced to ask for more permissions than desired. And you are at the
mercy of the third party. I don't see any way in which a third party
authentication service is a win.

~~~
big_lou
It's a win because users aren't forced to go through the typical create
username/password --> email verification --> sign in flow. Is it worth it to
the end user? Maybe, maybe not. But it saves them time, and there's lots of
empirical evidence that sign-up rates are drastically higher with social
login.

~~~
papsosouid
>and there's lots of empirical evidence that sign-up rates are drastically
higher with social login.

Where? I've never seen any evidence at all, just claims from social marketing
weasels. The only empirical evidence I've seen shows it doesn't help at all,
and that the majority of users don't like it.

------
frankcaron
I'm all for Oauth integration in principal, albeit the "standard" has its
(reasonable and well-criticized) issues, but I think there's more of a case to
be made here for what's important to highlight to avoid user error on the part
of the web browsers / clients themselves.

Maybe incognito mode should be the default state of any new browser install
and non-incognito is a preference or toggle? This would avoid mass consumer
public consumption auth issues.

------
benjamincburns
To me the moral of the story is to include a notice that the user has only
logged out of _this_ (the auth consumer's) site, but may still have an active
session with auth provider X. That exact language probably isn't appropriate,
but it's at least the information a responsible auth consumer should try to
convey.

------
diminoten
This is context scramble. Why would anyone think they'd be logged out of
Facebook because they logged out of a site that uses Facebook auth? That'd be
like expecting you to have to unlock your front door again because you locked
your car.

~~~
relix
Because else logging out is meaningless - just pressing the "connect with
facebook" button again would instantly the user back in, without asking for
confirmation or a password. Hardly secure.

