[Seth_Kriticos]

The most dominant reason for me not to sign up to most random services is that I'd have to manage another set of credentials. There are tools for that, but it's still a hassle (and I value my time). Just use SSO solutions like clickpass (I'm in no way affiliated, just the first thing that came to mind), and I might stick around, if I like what you provide.

[huragok]

That's a major factor why many of my new projects use BrowserID. The upsides are that I don't have to worry about compromised password or verifying email addresses.

The downside is that it adds a dependency on Mozilla to keep their service up and that it isn't widely adopted yet, but I'm figuring it has legs.

[StavrosK]

I use BrowserID because it takes 5 minutes to integrate, whereas styling and testing all the password change/reset/confirmation/whatever pages takes the better part of a day.

You don't have to depend on Mozilla, you can do your own verification if you like, so nothing leaves your site.

A side-project I made, http://www.yourpane.com, is even simpler: Just enter your email in the box and you get a sign-in link which you can bookmark. No passwords or anything.

[joshkaufman]

I'm curious about the YourPane login method. Is it open source?

[StavrosK]

No, but I just generate a token for each user and send it to their email when they request it (an account is created if that address doesn't exist). There's a URL that accepts the token and logs them in, that's pretty much it. Hardly anything to open-source.

[horv]

Even worse, as the article mentions, is having another set of credentials that you can't ever delete. I don't want hundreds of different websites all with an account for me that I'm not ever going to use.

[TazeTSchnitzel]

you can't ever what?

[antninja]

SSO is good for free apps. If I built a premium app, I would be reluctant to rely on Facebook or Twitter to protect my customers' paid accounts or the access to their credit card numbers.

[bunderbunder]

Totally reasonable. And as a social networking Luddite, I also appreciate you being hesitant to cut me out of your pool of potential customers in punishment for the offense of not already being a customer of an unrelated company.

But in turn, I might be reluctant to trust you with my credit card numbers. And to be honest I do get sick of having to come up with more un/pw combinations to remember.

What I'd really like to see more of is using OpenID for third-party authentication, and also some third party (I hate to say PayPal, but. . . PayPal) for financial transactions. Because it does save both of us from having to navigate that whole quagmire of trust & authentication yet again.

[AndrewDucker]

Not to mention that if you did then I couldn't log in from the office.

[Seth_Kriticos]

All valid issues, but none of them blocking IMO.

1. You'd certainly have to choose the right sources for SSO. I'd say people usually trust their Google account, so that's a good start (and Google does payments, so they make sure to keep it tight). Then go from there, I'm sure other dominant platforms have similar offerings.

2. You can provide an alternative set of credentials. HN is an excellent example. You can log in via id+password, OpenID or clickpass.

3. I will resist signing on until I know you (your application) better. It is more effective to get my attention first (with something like a limited intro, showing what's it about) and once I get hooked, present the payment options. Putting up a pay wall before showing anything is putting me off. Start with light authentication and then add to it once money enters the game.

ps. Requiring users to create new credentials also results in the "one password for everything" phenomenon that's so prevalent. I very much doubt that that will increase security. I'm more inclined to believe that it will do the opposite, as your service will most likely get the less secure/shared password from the get go (remember, you customers don't know how much they will value you later on).