Ask HN: How to you prefer to log in to websites?

[mathijs]

For a web based hobby project I want to allow users to log in and save data in their own accounts. I want to make this as simple as possible (both in terms of development and user experience) but I don't want to force users to use (for example) Facebook connect.

Here are a few pros and cons I've considered:

* Email+password. Pro: does not require users to have an account elsewhere. Cons: requires users to create yet another account; also requires me to write a lot of boilerplate code ('confirm password' functionality, 'forgot my password', etc.).

* Login with Facebook/Twitter. Con: forces visitors to have one of those accounts. Pros: most people have one of those; it allows login/signup with just a few clicks.

* OpenID. Pro: most people have this. Con: I'm not sure if the average internet user knows what it is (i.e. requires explaining that a Gmail-address is also an OpenID).

* Mozilla's BrowserID. Pro: seems easy to implement and easy to use. Con: I doubt that this is widely known and used.

What are your opinions as users? How do you prefer to log in? Any feedback is highly appreciated!

[bluesnowmonkey]

Email+password. As a user with a password manager (LastPass), I can log in with one click, use a unique password everywhere, and never forget a password. Can't beat it in terms of usability.

From the developer's perspective, there's a bit of boilerplate to be done, but it's nice to own the data and not rely on third party platforms.

I think there's an unfulfilled need for identity management by password managers. Why do I have to enter the same information everywhere? It would be nice to be able to click a "Create Account" button on a website and have it get my name, email, and new password from the LastPass plugin over a standard protocol.

[jameshawkins]

I agree - I don't use a password manager, but I find this to be the best option. I would suggest using email vs having the user create a username (email is always unique, but when you have a common name and your username is sometimes taken, you have to choose a secondary or tertiary username, which can get confusing).

I don't have any problems wit Facebook/Twitter logins, but I would suggest holding back on the permissions requests. If I see that a website wants to have the ability to post as me or invite friends as me, etc., I will think twice about accepting. If they just want to access my name/email for auth reasons, I'm usually happy to do so.

I like OpenID, but am not sure if it is as widespread among the average user (especially vs Facebook or Twitter) an having that as the only login option may shy people away a bit.

Haven't used BrowserID, so personally I wouldn't use it. I don't know the numbers on this one, but you may get a specific demographic of users if you go with this one.

[mathijs]

Thanks! I didn't think about LastPass, but since the website will be targeted (mostly) towards a hacker crowd it makes sense that many of the users will use a password manager like LastPass. I'm not a LastPass user myself but I guess that takes away a bit of the hurdle from a user's point of view.

[brudgers]

Somehow, I suspect that someone would build a website (or three) that would automatically create a new account for you just to collect your information.

[TMK]

I kinda like how easy facebook/twitter makes logging in to new sites, but I find it annoying when they request for permissions they do not really need.

Then again I like when a site allows me to create new account for the site, because this does not share my social data to the site, but the registration process is annoying, because I of course want to use the site right away.

OpenID is pretty cool system, but I do not use it, because I do not use any of the OpenID services like Google anymore.

Never before heard of Mozilla's BrowserID, so can not say much about it.

These days I have been thinking about system where log in form asks for email address and password. Then the client will send this email address to the server and the server will check if the address already exists in the database.

If the email does not exist then the server will reply to the client and the client will send the password to the server and the server will register new account and authenticate the user right away. Then the user can do whatever they need to do on the site.

If the email does exist then the server will reply to the client and the client will send somekind of hash generated to the server to authenticate the user. The hash function will use the user password as the secret key. Once the server receives this hash it will authenticate the account if the email and password were correct.

I think this kind of system would simplify the registration process. If you need the email address verified you can send the verification email on the registration process, but do not require the email to be verified right away, because it's damn annoying to go to your email to click the damn link to verify your email address which usually opens new tab in your browser when you already most likely have the site in open tab.

[jparishy]

I might be a part of the minority, but generally I would rather give up my (Facebook|Twitter|GitHub) account than create a new account, for a few reasons.

1. My email is more important. I generally don't want you to have it if I feel like you might bug me. I can disable your access to my info on Facebook (and usually do), but with email you can still send me things I don't want.

2. I don't want to have to sign in. With Facebook logins I can usually click 1-2 buttons and I'm in. That's what I want. Unless my interest is particularly piqued, I will probably just Cmd+W you out of my life. :)

That being said I would never do something like this for say, my online banking account. But for social/online services? I would definitely take this route.

[jancborchardt]

mathijs, you might want to look into remoteStorage. It’s an open protocol for per-user data storage. As it also has identification & authorization, the log in is inherent. It’s kind of like OpenID + Storage, except that we don’t use OpenID (but rather Webfinger, OAuth, CORS and Get put delete on a key value store). For a developer, you just put in the remoteStorage.js client-side library and that enables everyone to log in to your app with their remoteStorage.

Check it out at http://unhosted.org and http://www.w3.org/community/unhosted/wiki/RemoteStorage There is also an IRC channel, #unhosted on freenode.

[mindcrime]

1. OpenID

2. Email+Password

999999. Twitter / Facebook.

haven't used BrowserID enough to comment.

[nofavorite]

Email and password with option to connect via Facebook.

[youngdev]

Usually I rather create new account instead of giving my facebook info for the site I do not trust.

We went with approach A and B for our site http://jackpotbuddy.com. We kept the Email+password signup to just 4 fields (Name, email, password and confirm password)

[cmaxwell]

I give my users an option of email + password or Facebook.

Only about 1 in 3 choose the Facebook option.