That sums it up nicely.

And actually, the thing is I could totally see Facebook enabling truly 'anonymous logins' and whatnot, because it can afford to do it at this point. It is too entrenched as the social king, no other competitor comes close to it, and it's not going to fall down anytime soon because it'll be buoyed by networks effects for quite some time... and so it makes sense to ease things up a little to improve their public image. But, the way they got there, to the top, was by using dirty and despicable dark patterns, like 'Privacy Zuckering': http://darkpatterns.org/library/privacy_zuckering/ For this reason alone, I would stay the hell away from anything Facebook.

It does make sense though. Developers only really want a way to verify the user exists and isn't some spammy bot. Verification like facebook login is the easiest way to go. The problem has always been - far too many people avoid signing up with facebook as it shares "god only knows what" with the site. This works around both issues and really is the only way they can become the single signon entity. Which is what they've been aiming for.

As for "not bothering to implement" (aap), if you already need to handle facebook connect login, its going to be minor to add anon login facebook handles all the identity stuff leaving your app clean of yet another verification loop which annoys the hell out of users.

Sure there is the "apps need that data to make money" situation, but as a matter of fact, the people signing on anonymously were a) going to create a fake facebook or b) signup manually and give you a mailinator address.

Such as?

They're improving collaboration in all products, ie bringing it on par with gdocs.

Something geospatial, dont recall exactly what, maybe it was to do with SharePoint or colo.

The most interesting was they're letting go of forcing ms languages for plugins and allowing you to write and import widgets/plugins as html/js so all those nasty vb scripts of old are going to get some much needed love from all the web devs out there.

I could be wrong on a few of these just what I recall hearing about, happy to be corrected if I misunderstood any of what I was told. Mostly it just sounded like, as a company, they're identifying what their core products are and innovating on them. As in strategically, they're getting their shit together.

There's no doubt that Facebook knows who you are even if you use the "Anonymous" login. This just allows a user of RandomApp#100 to login without giving the app everything on their Facebook before they even try it.

Also even with anonymous login, you can later choose to give the app your real info if you trust it more or find it useful.

Do I like Facebook-only login? No. However, this does give the user some more choice as to how much is shared with those apps up front.

They'll probably introduce that reality once 'anonymous' mode has been established and depreciate assumed permissions as time goes on.

* What about the web?

* What about cross-platform?

* What about when the device token changes? (for example, after restoring the phone from a backup image)

My take: Facebook Login solves a real problem well and this 'Anonymous' option is a good improvement. The name is no worse than other industry uses of terms "Incognito", "Private", and "Cloaked".

on the web, anonymous login would be just a code snippet. What would prevent anyone from showing regular FB login posing as anonymous? Only thing I can think of regular login should have a follow up dialog with confirmation of what's requested, but maybe that can be auto confirmed too? some users may still agree to follow up screen if they trust the anonymous icon.

As for cross-platform and token changes -- well, you can't deal with those situations when you're implementing something that's actually anonymous. You're going to have to implement some sort of persistent identity. At that point, you might as well offer a multitude of options, of which Facebook would be one.

This login creates an unnecessary point of friction for all anonymous applications. Just use an existing token (cookie, device token, etc), allow your user to immediately begin using your app (that's what they expect anyhow), and "ease your user in" to a point of giving you identifying information if you need it.

Even if the cookie expiration was set for 100 years, it's going to disappear the moment someone switches their browser, gets a new computer, clears their cookies, etc.

True, but this login isn't "actually anonymous" - but I can't think of a better term so I don't blame Facebook for using the one they did. It's effectively a global ID with no data attached to it.

This seems like a reasonable solution.

> Just use an existing token (cookie, device token)

That won't work because the mobile and web account have to be connected.

Remember, if it was actually anonymous, you wouldn't need Facebook's help to implement it.

People implement FB login for a variety of reasons, but one is that doing proper account management is hard. If you want to implement a non-FB anon login, you basically have to implement a full account management solution yourself, assuming you want the anon account data to be persistent (that is, it's not truly anonymous in the sense that you sign in, do things, sign out, and it's as if you were never there). This basically fixes one of my final issues with FB login, that it's still not clear what data FB will give to the app. If anon login means FB doesn't give anything to the app aside from an opaque ID token, that's pretty cool.

That's just not true. Modern web frameworks come with modules that let one have fairly good account management systems without much work.

I do Python mostly. Django? Fine. It has an excellent auth system out of the box. But that kind of auth system isn't very flexible either. Now I barely do Django development today so please excuse me behind any insane changes.

Flask and Pyramid world? Custom auth to me. They both have community modules for auth stuff, but do I really like them? I am not the kind of guy just pip install random "useful" package these days. Let's give another example. A year or two ago I tried to do social auth in some of my django and flask apps. Maybe I was dumb but using that social-auth library took me a while to get some of login working. Plus, the code was messy and buggy. In the end, I said screw that and implemented all of the custom login myself, just reading the official doc from twitter and facebook. That also took me a while but I knew the whole implementation inside-out. If I don't trust my own implement because it is insecure, then I must spend the same amount of time inspecting other people's custom modules.

The truth is, generic auth system is hard and is not flexible. In fact, too flexible can be a bad thing: http://plope.com/pyramid_auth_design_api_postmortem

I like customized auth system based on the api provided by the framework - that' what makes Pyramid powerful to me. Sometimes your community auth module can have limitation that you probably have to hack around.

I'd like to setup an account management system and I was planning on doing it manually but figured there had to be a better way.

For Rails, Devise seems to be the way to go, as it's the most popular by far[0]. It's what I'm using for my project.

[0]https://www.ruby-toolbox.com/categories/rails_authentication

Most modern web frameworks do NOT come with fairly good account management systems.

    1. Python + Django 
    2. Node.js + whatever
    3. PHP + CakePHP/CodeIgniter/Yii

By "password-reset" I mean user clicks "Forgot password" and goes through some process like asking a secret question, doing catpcha test, sending a password reset link via e-mail, handling the click on the link, asking for a new password and resetting it.

P.S. Pick different frameworks if you wish.

Alternatively, there appears to be a CBV version of password resets over here that looks fairly easy to extend: https://github.com/brutasse/django-password-reset

I can't talk for node.js (although I have found that its authn/authz frameworks are lacking in general) or various PHP frameworks, but Django at the least is fairly professional.

Most people are going to access your app from one device, their phone. The phone is the one true source of identity. Let us all be glad that a privacy-paranoid company such as Apple sets the standards there, rather than what Facebook would have liked, had their phone efforts worked out.

I will also note that taking advantage of device token for "login-less anonymous use" is way way smarter for developers, from a usage perspective. Every single tap or interaction is a point of friction for your users; just eliminate them altogether. This is, for example, why TouchID-based devices generate more App Store transactions than devices based on the normal password system.

Everything else I use from multiple devices.

Using Facebook (or any kind of login) to solve that would be a bad idea (but many might be tempted to do it).

However, in those cases when the task is more complex than that (I just checked, that applies to eleven† of all 23 third party apps I have installed on my iPhone) that’s not a solution. I – the user – want to be able to access the data from anywhere and do actually use that functionality regularly.

Honestly, I personally would have no issue if each of those apps gave me a choice of signing up with either Google or Facebook. That would massively simplify things for me and I wouldn’t have to lug so many accounts around. I can understand the privacy concerns, so I do see the need for alternatives, but for me personally it’s not an issue.

—

† Reeder, Twitter, FB Messenger, iBooks, Pages, Keynote, Numbers, YouTube, Twitch, Vine and Dropbox; Apps that already don’t force me to log in, most because it’s just not necessary: Castro, arte, Star Guide, six game apps; Apps that force me to log in for some functionality and I’m not sure how I feel about them: iPhoto, iMovie, Remote.

‘Often’: many websites don’t see this; I’m willing to bet those I use regularly (StackOverflow, HN) aren’t even close. Most analyst describe a currently slight majority for phone metrics (except time on the site); more importantly, demographic elements suggest phone attention share will grow.

> I'm truly sick of hearing that the phone is the only device that matters.

‘Only’: OC hasn’t said exactly that -- he talked about authentification; most people don’t really say that either. Many journalists exagerate a trend and slight majority, but I would (tongue-in-cheek) blame you first for reading badly written magazines.

My experience is that authentification is safer for non-developer users on their smartphone: you have a lot more stream for consistent two-factor authentification; physical security is better for something in your pocket most of the time; it’s the only random-key generator (capable) most people have close to them. Roughly half of users users actually lock the damn thing…

Lose your device, lose your account. Yay!

- Exactly and I don't even bother signing with Facebook account anymore with most of the apps, Facebook apps are way of the past.

I could claim client-side certificates, but nobody uses those, and certainly not cross-platform.

This is a big win for users who don't want to share their personal data with a random app developer. Facebook still sees your activity, but they already saw your activity.

This for the millions of users that want to try apps without having to fill in multiple onerous registration fields and without having to worry that if they use facebook login, the app will spam all their friends and post to their newsfeed.

This is actually very smart, and I will be implementing it soon. Definitely not an "idiot" move for developers to implement.

Src: http://www.insidefacebook.com/2012/09/24/facebook-partnershi...

Can someone give me some perspective on why Mozilla's Persona is not used more for authentication purposes?