Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building account systems

blog.plan99.net

Post reply on HN
Print view View original

31–40 of 58 posts

Re: Building account systems

#31

Post by jimktrains2 »

homarp wrote: post #25

>Often web developers see adding a “sign in with Facebook” or “sign in with Google” button as a kind of optional nice-to-have, which comes only after building their own account system. If you’re reading this because you’re starting a new website from scratch, I argue that “Sign in with …” should be the only option you offer. unless you have potential clients in China.

I hate and never use "Sign in with ..." as I don't like my identities to be closely tied together like that. I avoid giving Google and Facebook any information I can't avoid/don't want them to have.

Re: Building account systems

#32

Post by pfranz »

jopsen wrote: post #27
noir_lord wrote: post #8

Earlier quoted context omitted.

Yep, side project I'm thinking of playing with in a month or two when the batteries are recharged pretty much completely rules out using either (health data). I wouldn't sign up to my own side project if I had to use either in that case.

I'll have to admit I prefer services that has a "sign up with" particularly google, github or facebook in that order :) It's one less password to manage...

I feel like an old person for hating those things.

* I have a password manager because I have to manage 100s of passwords already and most aren't moving to Google anytime soon. * There are a few occasions where I've had to share my credentials with friends or family. It's nice to change the password temporarily and not give them access to my whole Google account. * I don't want to sign into Google on every devices/computer. Similar to the passwordless recommendation: I don't want to sign into email on every device I use the account on. * I don't want Google to know anything about me it doesn't have to. I have a Facebook account and Google account, but I rarely log in. I switched my email away from Google years ago for this reason. * What if I want to create a test account or second account to play around?

I like the idea of single signon, but I don't trust the Big Boys with my data. Exclusively having "sign up with" buttons usually makes me leave the site.

Re: Building account systems

#33

Post by Terr_ »

homarp wrote: post #25

>Often web developers see adding a “sign in with Facebook” or “sign in with Google” button as a kind of optional nice-to-have, which comes only after building their own account system. If you’re reading this because you’re starting a new website from scratch, I argue that “Sign in with …” should be the only option you offer. unless you have potential clients in China.

Personally, that drives me to a competitor, especially if the site offers absolutely nothing I'd ever want to integrate -- or have someone else integrate -- into my real-name persona.

Re: Building account systems

#34

Post by lewisl9029 »

Terr_ wrote: post #2

> If the username becomes a form of self-expression on your service, users will want to change it from time to time. IMO separating identity from display-name is an under-used design choice, especially if you think your system needs to scale up to lots and lots of unique accounts. I think Steam is an easy example of a service which does it right: Many people (usually in different social circles) can use the same name…

> I think Steam is an easy example of a service which does it right: Many people (usually in different social circles) can use the same name, you can change your display name easily, other people can see some previously-used names, and you can assign custom names to friends to avoid confusion.

On the other hand, they won't let you change your login name, which would hint that they're using it as a unique identifier of some kind internally, which seems like a bit of an antipattern.

Re: Building account systems

#35

Post by chipperyman573 »

lewisl9029 wrote: post #34
Terr_ wrote: post #2

> If the username becomes a form of self-expression on your service, users will want to change it from time to time. IMO separating identity from display-name is an under-used design choice, especially if you think your system needs to scale up to lots and lots of unique accounts. I think Steam is an easy example of a service which does it right: Many people (usually in different social circles) can use the same name…

> I think Steam is an easy example of a service which does it right: Many people (usually in different social circles) can use the same name, you can change your display name easily, other people can see some previously-used names, and you can assign custom names to friends to avoid confusion. On the other hand, they won't let you change your login name, which would hint that they're using it as a unique identifier o…

Every account has a (public) 32 bit ID, it's unlikely (though possible) that they use the login name for anything more than logging in.

Re: Building account systems

#36

Post by yorwba »

zyb09 wrote: post #28
homarp wrote: post #25

>Often web developers see adding a “sign in with Facebook” or “sign in with Google” button as a kind of optional nice-to-have, which comes only after building their own account system. If you’re reading this because you’re starting a new website from scratch, I argue that “Sign in with …” should be the only option you offer. unless you have potential clients in China.

Anyone know if there is a good commonly used Chinese OAuth provider? Or Japanese and Korean for that matter?

I found this related Quora question: https://www.quora.com/Is-there-an-equivalent-of-Facebook-Con...

Of those mentioned in the answers, I think QQ would be your best bet. I have never seen anyone use Renren, but everyone seems to have a QQ number.

Another of those "everyone has it" apps is WeChat, which also provides OAuth: http://open.wechat.com/cgi-bin/newreadtemplate?t=overseas_op...

Re: Building account systems

#37

Post by benpbenp »

Terr_ wrote: post #2

> If the username becomes a form of self-expression on your service, users will want to change it from time to time. IMO separating identity from display-name is an under-used design choice, especially if you think your system needs to scale up to lots and lots of unique accounts. I think Steam is an easy example of a service which does it right: Many people (usually in different social circles) can use the same name…

> and also unambiguous to future-me. Ex: "Your worst encounter with bees occurred in what place?"

Optimistically assuming your worst-bee-encountering days are behind you, of course.

Re: Building account systems

#38

Post by inopinatus »

Terr_ wrote: post #2

> If the username becomes a form of self-expression on your service, users will want to change it from time to time. IMO separating identity from display-name is an under-used design choice, especially if you think your system needs to scale up to lots and lots of unique accounts. I think Steam is an easy example of a service which does it right: Many people (usually in different social circles) can use the same name…

The trouble with that is that now you can never relate your amusing/horrifying story about the bees. Also consider the worrying possibility that you may have another, even worse encounter with bees.

I had a similar recent experience (not with bees, with security questions) whilst joining the Apple Developer programme. All the questions on offer assumed a conventional middle-class American upbringing and referenced experiences and institutions that I have simply never encountered. This is not unusual. Fortunately my password manager generates all the fake cats & cars & prom dates I never had.

Re: Building account systems

#39

Post by inopinatus »

> Use email / phone numbers to identify users

This isn't always good advice. Not everyone has a unique email address, and not everyone has a phone number.

If you're dealing with technology-savvy adults, sure, go ahead.

But demanding a unique email address or phone number is actually a high barrier for many people. Case in point, my services is used by families. It's common for them to share an email address, or for the youngest and oldest members not to possess a personal phone. They also frequently lose access to email accounts e.g. when changing ISP, which makes account recovery a painful manual process.

So we use a domain-specific identifier combining a generated membership number and the family name, and this works out well.

Bottom line, consider your user base when establishing an identity scheme. Don't blindly accept prescriptions for your data model.

Re: Building account systems

#40

Post by PaulRobinson »

benpbenp wrote: post #37
Terr_ wrote: post #2

> If the username becomes a form of self-expression on your service, users will want to change it from time to time. IMO separating identity from display-name is an under-used design choice, especially if you think your system needs to scale up to lots and lots of unique accounts. I think Steam is an easy example of a service which does it right: Many people (usually in different social circles) can use the same name…

> and also unambiguous to future-me. Ex: "Your worst encounter with bees occurred in what place?" Optimistically assuming your worst-bee-encountering days are behind you, of course.

Lying in the hospital bed, the "Get well" cards decorating the space around you, the creams and ointments soothing, you realise you haven't checked your bank account since The Incident.

You pick up your phone and log in to internet banking.

"Oh no. Oh no, no, no. Why is it taunting me? Sacramento was _nothing_ to this. _Nothing._"

A tear rolls down your cheek.

Through the window a lone bee watches. The tear it sees is good, but not enough. It will go back to the hive and dance to communicate to the others your pain, but their ultimate failure in their plan. They will regroup. They will be back.

Post reply on HN