Building account systems
blog.plan99.net
blog.plan99.net
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, 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.
> Pre-supplied questions make the guessing problem worse.
Personally I've love to have the option of choosing my own question.
All too often the pre-supplied questions suck in various ways. Some might be patently insecure (ex: name of highschool), inapplicable (name of first pet) or just too ambiguous to rely on (name of street you grew up on, if you moved a lot.)
With a custom question, I could craft something both secure (at least against non-family) 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.
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.
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.
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.
Come to think of it, that also serves as a counterexample to one of the article's pieces of advice: using an email address as the users login. Steam used to work that way, which is why I have to log in using a string which is an email address I don't use anymore.
The one true pattern for auth/identity has been known a long time:
http://habitatchronicles.com/2008/10/the-tripartite-identity...
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.
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 while for an email to be delivered. Requirement to stare for 3-5 (or more?) minutes into a screen of my mail client and obsessively click on refresh button is less than ideal, and would just get more and more annoying the longer one uses the app. And even if email arrives immediately, it's still more steps and time then having my password manager auto-fill the form and log me in.
Also a (minor) annoyance with this is that clicking on the link in email will open a new tab/window in the default browser, not reuse the one where I started the login process.
And then you have a full bag of all the usual problems with users not getting emails for various reasons, from being marked as spam, to simply moved to Updates tab in gmail, where you can bet that half of your ordinary users will not be able to find them. That will generate your support team some steady flow of extra work, you can bet on that.
From my personal experience, 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. You can try to manually follow up with email in a few days, to offer assistance, but most of them will never reply.
By using this approach, you're forcing users into switching their mental context and attention between your app and all the other emails arriving to their inbox, all the notifications on social media, all the other distractions around us. And you can bet that they care much more about any of that than about trying out your app.
If I have to read an email in order to sign in to a web app or website on my phone, that means I need to get on my computer and go to fastmail.fm. Which is inconvenient.
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...
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.
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).
Offloading this is a huge privacy fail. It probably is a security win, but it's a huge privacy fail. Here Google/FB/etc, get MORE information for your giant catch-all, know-all database, thanks!
Unfortunately better alternatives that are not a security win don't really exist yet.
Asked another way -- if I sign into a website using FB auth, am I also signing into FB itself at that time? And so can be tracked around the web as if I had logged into FB directly?
That in itself could be giving away a lot of personal information. Merely knowing that someone visits a particular web site regularly could disclose their sexual orientation, health/mental issues, financial status, religious or political affiliation, etc.
If FB or Google then starts serving you ads that reflect these associations, it could publicly leak information about you that you don't want leaked. In some countries, having the "wrong" sexual orientation or political association could be deadly.
But just the fact that an app uses Google authentication doesn't give Google any kind of privileged access to that app's data (beyond purely the data that they're logging in on this browser at this point in time) unless the app is pushing data actively back to Google (which they could do anyway for a gmail-managed email address, I guess) or you believe that Google will then subsequently forge authentication requests to that app and pull data out itself. Both of these things are hypothetical violations of your privacy enabled by using auth-with-Google, but for most use cases are rather unlikely, I would guess.
For that they handle the complete user registration, recovery & auth process for you, with all the work and pain attached to it.
Granted if your OAuth provider were really evil, they could log into the users App X account and access whatever data he has inside the app, so you have decide if that a concern or not.
For a hello world app, no big. For a game app, what happens when your employer buys the data, and notices you are playing games on "company" time... Of course lots more privacy failures can be easily imagined here. I picked low privacy failures, but larger failures are very easy to imagine.. Especially when we know that most large governments also have this data, directly siphoned from Google/FB/etc.
For some applications, that privacy loss may not be a big deal. Except if you combine this information with the other 500 web apps the user also uses through 'Sign in with...' links, plus all the other information they gather, they suddenly get to know you really, really well.
I wouldn't sign up to my own side project if I had to use either in that case.
It's one less password to manage...
* 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.
I wish we had better federated sign-in solutions, but open-id probably won't be it... and U2F while cool won't solve the account recoverability problem.
unless you have potential clients in China.
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.
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...
I was looking into getting my app translated, but haven't even thought about OAuth providers.
I agree that WeChat is more popular, though. Those who have both my QQ and WeChat contacts overwhelmingly go though WeChat.
An account system using phone numbers may have a negative impact to privacy. For some people a phone number is attached to a real name and address. Also it is not uncommon for a person to change their phone number from time to time.
Does it mean to use a entirely new-domain.com or use marketing.domain.com?
Oh, so basically scripture then.