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

41–50 of 58 posts

Re: Building account systems

#41

Post by GordonS »

inopinatus wrote: post #39

> 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 t…

Some services (including Gmail, I think) let you link multiple email addresses to an account. That could be useful if you lose access to one of your email accounts.

Re: Building account systems

#42

Post by hardwaresofton »

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…

One counter point -- it's pretty hard to add new steam friends by ID because often it's hard to figure out exactly which name to search for in their online tool.

You can't really add people by direct username, so you have to go by their most recently used nickname, and you get some complexity that you don't expect as an end-user.

Re: Building account systems

#43

Post by a_imho »

1. Using 3rd party auth is much more convoluted than rolling your own. There are key turn solutions for every framework and you don't have to register your product with other services, agree to a bunch of terms, introduce dependencies in your stack and essentially give control over your app.

2. Being stuck in a perpetual password reset scenario is one of the worst UX decisions imo. Going to an email provider to access a completely different service is getting it all backwards (and users will have to type in their passwords anyway). Plus email has its own baggage like spam filters etc.

It is very much up to taste, but personally I would even argue for the opposite: we could do away with forgotten password links altogether (or at least make them optional) and trust users to handle their passwords how they wish instead of collecting email addresses (like HN).

Re: Building account systems

#45

Post by wmccullough »

jlgaddis wrote: post #19
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 simply generate non-sensical answers regardless of what the questions are. For example, "What is your favorite place to go on vacation?" was a security question I recently encountered. My answer was something absurd, along the lines of "FourteenZebras".

Ok

Re: Building account systems

#46

Post by ubernostrum »

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…

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.

The one true pattern for auth/identity has been known a long time:

http://habitatchronicles.com/2008/10/the-tripartite-identity...

Re: Building account systems

#47

Post by _cereal »

ivanhoe wrote: post #5

Many solid advices here, but I still have doubts about the real-life UX of switching to emailed links instead of using passwords. It's quite popular for some time now, and security wise it makes a lot of sense, but: For one, that means that each time I wish to login (or switch between accounts) I need to fill my email and then go to another tab or to mail app, and wait for the email. It's not that uncommon to take a…

> each time in some app we were forcing users to confirm their email address upon registration (non-tech founders often insist on this for some reason) we'd see between 40% to even 70% drop. People would register and then never come back because they just didn't care enough to look for our confirmation email.

Some countries in Europe require to prove user opt-in consent, in addition the EU General Data Protection Regulation (GDPR)[1] approved in 2016 and active starting from May 2018 will, in practice, extend it to all EU countries.

[1] https://en.wikipedia.org/wiki/General_Data_Protection_Regula...

Re: Building account systems

#48

Post by Monotoko »

yorwba wrote: post #36
zyb09 wrote: post #28

Earlier quoted context omitted.

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

You would not use QQ these days, it would be Wechat instead which pretty much everyone online in China has. QQ died around 2013

Re: Building account systems

#49

Post by zyb09 »

yorwba wrote: post #36
zyb09 wrote: post #28

Earlier quoted context omitted.

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

Good links, thanks. At WWDC Apple was saying that Chinese, Japanese & Korean localisations for iOS Apps are often overlooked, and their data shows they should be the first ones to be added after English, even before localising for the more traditional languages.

I was looking into getting my app translated, but haven't even thought about OAuth providers.

Re: Building account systems

#50

Post by ehnto »

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 did find that an odd comment. I understand the assumption is that you will eventually roll your own (perhaps?) but to imagine requiring a user to be part of those services to use your own service, especially of your service has nothing to do with those, is very strange. Just a few examples of how that could become a pain for our pretend user Greg:

a) The obvious, Greg simply does not want a Google/Facebook/etc account.

b) Greg is from a region that does not have strong Google/Facebook/etc uptake and does not have one.

c) Greg is from a region that actually disallows those services, making your service blocked entirely.

d) Greg does not want to link his 3rd party account to your service.

Lastly if you are targeting enterprise clients: Greg is signing up to your service for a company he works for, not for himself, and there is of course no "Company Facebook Account". If his company uses Google Mail then he is in luck, but if not then there is a whole new account management process to go through. Someone will inevitably leave the company, lose the credentials, forget they ever had an account in the first place or remember they had an account but forget the new 3rd party services password instead.

Not to mention, if you are running a company, relying on a third party for such an important part of the puzzle is putting an enormous amount of trust into that third party. I know there are lots of those trust connections to take into account in any business, but if I am in the business of writing software it seems odd for me to not have the confidence and ability to manage an in house accounts system.

Post reply on HN