> 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, 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?"
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.
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.
> 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.
While I would like to change my login name, the important thing is that it's not used anywhere else. This means it does not get in the way of my self-expression, and also that nobody who I talk to through the system can harass me by repeatedly entering wrong passwords.
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.
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:
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.
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".
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 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.
The problem for me at least for mobile access is that I do not have my "real" email tied to my phone. I have an Android phone, but have a separate gmail address that is only used in relation to the phone (activation, google play account, etc.)
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.
Very similar for me. The only emails I get on my iPhone and/or iPad are alerts for $work. For anything else I have to pull up my mail client (I don't use webmail) so it's a huge pain in the ass. I'm hoping this method of "authenticating" quickly dies out.
If you're requiring an email/login and 40-70% of users never confirm or bother coming back, perhaps your product isn't something they really want. Personally, I hate being forced to go through the process of creating an account only to quickly discover that I'm never going to use application/website/whatever again.
I'm talking about the situation where you can't login into the site without first confirming your email. Yeah, I know it sounds crazy, but owners initially insisted on doing it that way on two separate projects I was involved with. So customer has never seen the actual product. They'd register and then instead of immediately going to their email client to confirm it and login, they'd go somewhere else, and never come back to test the product. In many ways this is a similar process to the one with password links, and I think it would have the same effect.
> 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.
Agreed. And furthermore, some corporate email filtering can delay receipt of emails for HOURS, making it literally impossible to login under certain circumstances, which in my own experience is insane and enraging.
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.
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.
Most definitely not in the circumstances I just described. Again, that's a solution only a tech-savvy user will find accessible. I'm not designing for my peers, I design for real people.
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).
Another issue is what privacy are you losing by handing FB or Google all of your authentication?
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.
What privacy are you losing? Real question. You're probably revealing to FB or Google that you're a user of web app X, but beyond that? Does using FB or Google auth enable any additional tracking of activities within the app or site? I would think only if the site developer was using Facebook or Google ads or tracking anyway.
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?
"You're probably revealing to FB or Google that you're a user of web app X, but beyond that?"
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.
I believe that sign-in-with-X implementations require actually authenticating with X in that context. So in order to sign in with Google to a website, I need to sign into Google itself in the same browser. So in that sense, you are enabling Google to track you in that browser - but no differently than if you just logged into gmail. You could sign back out of Google immediately afterwards.
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.
It's not that bad. The only thing Google/FB/Twitter gets to know is that a user Y is using app X. Nothing more, and not detailed usage stats, just the basic fact.
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.
Yes, but they get "only" that, but with it, they get, time/date of when you use the app(and perhaps how long, depending on how you/they handle logouts). Plus they get this for EVERY app that's used. You start aggregating this information and suddenly you can tell a LOT about a person. Plus this is all for ad dollars, FB/Google/etc can(will/do?) sell this information, to anyone willing to pay for it.
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.
Exactly, Google, FB, etc. They require you login to their website. They also now know you use web app X, the date/time, how often you use said website, 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.
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 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.
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.
>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.
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.
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.
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.
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.
I wouldn't say that QQ is dead, I have definitely seen people use it on their laptops in class at uni. A number of classes also used QQ groups for announcements, Q&A, etc.
I agree that WeChat is more popular, though. Those who have both my QQ and WeChat contacts overwhelmingly go though WeChat.
> Users are always identified to you by email address, phone number or both...
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.
I've seen instances of using example.net instead of the primary example.com domain, but as a user I prefer subdomains. It's easier to confirm ("visually", just from the domain name) that it's actually coming from the same company and not a phishing email, for example.
If you're building some sort of ad supported and public site, using Google or FB accounts is fine, but it's not always workable if they're paying you a monthly fee. People will want administrative control over accounts, and they'll call and demand you fix things when they can't login.
In fairness this is more then rehashing NIST 800-63. This is coming from a Google engineer who worked on their authentication systems. A lot of good advice here, starting with not building your own.
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?"