In my services I usually use concept of identity associated with user account. Each account is allowed to have multiple identities, which can be used for credentials reset, login etc. The business data is always linked to an account, not to identity. Identities can be email, phone, username/password pair and 3rd party service account. This approach allows to fine-tune your security by customizing authentication/reset policy for each identity type and giving user enough flexibility.
I think this is definitely the way to go for any modern login system that plans to support multiple external OAuth providers in addition to its own internal email/password identity.
Decoupling the account from the identity allows users to log in to the same account with any identity provider, and have access to all the private resources associated with any external identity within that same account. Think of a storage service that aggregates user data from Dropbox, Google Drive, and OneDrive, and allows you to log in with any one of the 3 OAuth providers to access data from all 3. With a naive model that couples identity to account, this kind of identity federation would be much more difficult to support and extend to additional identity providers.
For those looking to implement support for identity federation in a microservice environment, I'd highly recommend taking a look at Dex from CoreOS: https://github.com/coreos/dex
It provides a consistent OpenID Connect based interface to multiple identity providers and identity management systems, for your backend to interact with (i.e. Dex talks to identity providers using whatever protocols they support, and your backend talks to Dex using OpenID Connect).
It's a good one, but it seems that there's a trade off with this design. Either you have to ask your users to enter all this information (not a good user experience), or, you end up with inconsistency in your model when you try to query by # number or email or any other "optional" Id's. Querying by UUID makes your app use cases fairly narrowed.
No, there's no trade-offs. From UX perspective, of course, user is not required to enter all this data. This is for his convenience, so he is required to provide bare minimum of information by his choice. However, for some functions security requirements are elevated, so he may be required to enter additional details or provide additional means for authentication.
I usually model it so you have an Account model, which in itself is nothing more than a table with UUID and metadata like creation timestamps. Then you can have EmailIdentity, PhoneIdentity, FacebookAuthIdentity, etc. that are linked to the Account.
In a simple service you can start with just a foreign key from EmailIdentity to the Account. This allows multiple email addresses to be tied to a same account and the same account to have multiple authentication methods or identities (Facebook, email). This way you can implement e.g. changing email address by actually adding an email address and verifying it first, before deactivating the old one.
When you start to need e.g. organization accounts (think about services that have both personal and organizational aspects: Facebook with business pages and ad management, StackOverflow with companies), you can either tie the identities or personal Accounts to the organizational accounts, depending on the model you need.
It can be often useful to add Person model to the mix, which models a real person behind multiple identities / accounts, but this depends on your service.
When they sign up, they probably have to choose (at least) one of those options, so that can be included on their profile and the data can be separated from the profile. E.g. Your "profile" in the db can say "login_type: phone_number", which is supplied when you sign up or your profile is created, and then you can do a lookup on the respective table. You could likely make it simpler and just include it in the profile table (phone_number, username, email columns) since there would only be a set amount of login types (unless you somehow make it generic and augmentable from a UI).
There's nothing special from architecture perspective. Identities are necessary for login and for some tasks related to outgoing messages to user: thus, authentication (OAuth2-based server) works with identities and during the login finds the related account and grants necessary permissions for it. Resources requiring personalization (information from account), will have the account id. If they need to contact the user, they'll request message delivery by this account id - respective service will figure out, which identity has to be used for this delivery.
Thank you for thinking about the user experience. Recently, I had to forcibly change an email address that I had in my possession for over ten years. The service was shutting down.
It was incredibly annoying to change this value for some of the sites I had accounts with. Some of them assumed I had access to my old email!
Suggestion:
So, I would prefer you build into your design the concept of an "identity". The identity is me! I can paste (I use keepass) in an email or my username. Your software can figure out which one I'm using. Also, please allow me to use long passwords, and don't disable paste with JavaScript! Also, allow the email to mostly be a hidden key. I only want to use it to interact with you, not something revealed to the public at large.
iTunes lets you change the e-mail address associated with your account, but not your account name.
If you use an e-mail address as the account name and then that e-mail address goes away, you may be in for some serious hurt when you try to change the associated account.
I would steer away from using a username as a login. A person's default username may be taken on your site, in cases like these people usually use a variation by appending some numbers/characters. Now, when they try to login they'll use the default username first because they don't remember. Using email removes all these barriers.
Why even add a username? I usually don't add them unless they are necessary (in cases where a user's profile, other information needs a pretty url)
Particularly, services which insist on you logging in with a username, but can send you your username by email if/when you forget it, should suffer horrid flaming death.
My god yes. I get caught up in this with Steam maybe once a year — frequently enough that I grimace in irritation at every Steam login prompt. Repeated logins using my email address and password, increasingly obscenely expressed frustration, follow the password reset process — emailing me a reset password link, at which point I usually remember why this keeps happening and go back to login with my username.
I mean, I understand that one could make a case for such a high-value target as Steam to not allow email/password pairs considering the high rate of password reuse. But I have 2FA enabled as well for heaven's sake. And I cannot believe that simply insisting on username/password pairs instead is better enough to justify it, compared to real best practice password policies. I mean jeez, how many username are just the pre-@ portion of the email address anyway??
On my desktop, Steam remembers the username, and just asks for the password. Do you do anything particular that causes the username to vanish? (I could only think of switching to a different account.)
I think the people in this thread saying things like "getting an email account is easy" need to spend more time observing some non-tech folks using a computer. Because actually that is a substantial barrier for ordinary people.
My service accepts both an email address and a membership number, and this helps enormously with account recovery in the astonishingly frequent case that someone changes job or ISP and loses access to their original mailbox. And it's amazing the number of people who mistype their email address.
For sign-in, we accept either and simply detect which one was used.
This also helps us to support multiple profiles per email address, which is a common case for families using our service.
Is getting an email address for tech folks even "easy" these days? Most services now seem to require a mobile phone number (virtual numbers like Skype numbers seem to be excluded). There are also various mobile operators whose numbers don't work, for whatever reason.
I've personally found getting a new address from gmail etc often problematic.
Gmail maybe, making an account at mail.com was dead easy. On the flip side, you have to keep pointing out "mail, without a g at the beginning," so who knows if that's worth it.
Gmail actually banks on the idea that most people just fill out whatever fields they are presented. The phone number is not actually required to register an account.
I would be questioning if people without an email address are actually going to be interested in using anything I am building. In most cases I would imagine not (but my company's target market is 18-25 year old europeans).
Rather than imagine, you should probably do some market testing. Here's a single data point to get you started: last time I talked to a late-teenage member of my family about email, they called it "old", and weren't even sure what their address was.
The beauty of just collecting an email is that you can use that for everything, including a lost password. Since most of my web apps are more private and account-based without communication among users, I tend to just create the account with an email and password.
I am working on a web app though that is more social, and I'm implementing something similar to Hacker News. Create a username and password and you are in.. with the option to set an email for password recovery and display purposes later on.
Depends. I worked on a software for school which will be used by young children to learn spanish. It was a strict requirement to have usernames because these children don't even have an email yet.
Another advantage of usernames is to mask the email address specially if you run public forums etc. Also, this allows changing email address without losing identity on front end as you obviously dont want to display the database table id.
> you obviously dont want to display the database table id
Why not? A lot of services assign a user ID (literally a number) or contract ID, which I can read to the customer service rep on the phone so they can quickly find my account without having to go through the trouble of mistyping my given name (see username) at least once.
How about giving people the choice to choose whether they want their login to be an email or a username. It's daunting task for developers, but at the end of the day, we write code to make people's lives easier, correct?
"I've always wondered which one of the two is more user friendly".
Well, I'd say neither one. I personally prefer OAuth and a sign in with X (github, google, facebook, etc).
This gives the user the most flexibility and quickest/easiest sign-in/register experience. They also get to pick and choose what you get access to and depending on what you need the user might not have to even give away his email.
But I'd give the option for email or username too, because some people like myself are oldskool and don't want discrete identities linked together.
But for OP - prioritise it. You could design for a plethora of options. Choose the easiest use-case for you and your audience, and then do other higher priority stuff, and then come back to lower priority login method choices.
What I hate is some stupidly strict password (numbers letter and special chars) for logging into something which I don't care much about - like some companies corporate jobsite. Whats the worst that can happen? Someone finds information about me that is already publicly available on LinkedIn.
As a user, unless I'm logging into and using your product everyday, I'll definitely forget my login id in a few days and then go through the headache of trying to find my login id etc leading to a poor experience.
So unless you have a very good reason to do something different, stick to login ids as email ids
If someone uses their work email as a username, they loose their ID if they leave the job. Even worse, the employer may give the same email address to someone else.
I think a username works better here. Gives users more of an ability to customise their profile than an email would, might be a tiny bit more secure than with an email address (since someone with a hacked list of emails and passwords can't just test them out on the login form) and generally I feel it looks better to have a human readable username than a generic email address to log in with.
More importantly however is giving the user a way to choose what name is displayed in their profile/next to their content, and not doing stupid things like forcing a name based on the email address or trying to take the first and last names from a connected social media account.
Funny that you should ask, yesterday I wanted a fast and simple way to do logins for a side project I'm working on and ended up writing a quick Django library that does passwordless authentication over email:
I would say email is significantly better than a username, as long as the user can change their address. An email is just much easier to remember. Of course, if your identifiers are ever going to be public, you need a username.
We have already had a hard time selecting a email username (the part which comes before @). Now if you ask me to choose another username, I am going to be wanting the same email username because I do not want to remember another name. Its more difficult than remembering passwords. If your service becomes extremely popular then I will not get a proper username available (if I am one of the late to party guys).
So avoid usernames at all cost. Email is longer, but more often, who needs to enter it again and again, we anyways store it in stored passwords on chrome etc.
> I've always wondered which one of the two is more user friendly - a username or an email?
An email as either a login or the sole recovery mechanism means your user's accounts can be permanently lost (or impossible to create) depending on some other service providers actions. It's pretty much the same problem as OAuth only (relying on external providers), without the convenience benefit of single sign-on.
OTOH, if you are willing to use email-only recovery (and most services are), there is no additional harm in email-only logon.
Just curious for people who are advocating for email how they deal with the following situations:
1. The user gets a new email address. Instead of updating the email address on their existing account, they create a new account. Then they are confused when none of their data from their old account shows up when they login to the new one.
2. The user gets a new email address and no longer has access to the old one. Then they forget their password and are unable to reset it because the reset email is going to a dead email address.
1. This looks like a normal use case. It depends on your business, if you end up collecting more than just an email (e.g. SSN, phone #, etc.), then you can add a logic to prevent the creation of a new account from the same user. Otherwise, it looks just like the creation of a new account and shouldn't be handled has an exception by your app.
2. On the user side you only present an email as a login. Though, on the implementation side you still need a user_id as your primary key. You can update the email attribute at anytime for an existing user_id. That involves an extra step to setup some sort of security questions so that a user can update the email address without having to access the account.
It might be harder to do but it should be both since I use throwaway emails for new sites I discover but don't trust and remember the usernames. And register with email so I could do password recovery in cases I trust. I'm sure a lot of people do this.
it was always a big question in front of any product person.
It was primarily relized by user's own behaviour, people started using so many sites, it became almost impossible to keep a seperate user name for so many logins. In case they tried having a usique namer over a new property, sometimes it was avilable sometimes it wasn't.
Hence, email based login became omnipresent
Social logins / Open authentication were also tried. They are at many places, but they also pose some challenges.
There isn't a simple answer yet, but may be in the future, a device based finger printing, eye scanning or something else may be the answer
For now, or some years back actually, I gave up and chose Email based authentication.
Would you clarify why it's worse to use an email address than a username as an internal key/identifier? It seems to me in either case you suffer the problem of, if the email or username changes, needing to update all the "foreign key" references to the identifier throughout your database.
no one is talking about the audience you are interacting with. Not everyone has an email and that does not mean they have to remain excluded.
Mobile phones are becoming a universal device, be it a rich or a poor, each one is going to have one. Hence the easiest and unique identifier is their phone number.
Now phone number is personal and could be easily tracked but the kind of audience that engages with phone number as a username is not much privy about their information when it comes to solving their problem or making their lives easier. The onus is on the system to make it entirely secure. With every data point, comes more responsibility.
OTOH it is pretty easy to get a free email address if you don't have one already.
However getting a phone number can be more work and isn't usually free.
Remember also that people may want multiple accounts on your service, ie for work and personal. Or for special purposes. (eg I have a couple of twitter bots but I'm only allowed to attach my phone number to one account).
Many people actually change their phone numbers. Especially in India, a lot of young guys change their number to the provider which has a better plan at the moment.
I worked for a big company that spent considerable effort to migrate to an email-as-username solution. Not sure about the background but likely well researched. For big companies, these are definitely not arbitrary choices.
