An email is usually longer and involves special characters. A username on the other hand is usually easily forgettable.
So what is the best practice when it comes to picking up a user login attribute?
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.
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 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.
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.
Been there, done that.
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.
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??
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.
I've personally found getting a new address from gmail etc often problematic.
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.
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.
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.
If you don't NEED a username, refrain from using any, it's just annoying. Worse yet don't require one.
I used to require a username on my site but I chose to take it away because it meant nothing since I was collecting emails anyway.
My heuristic is if they interact with other users: Username.
If not, email.
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.
While that may cover most people, there are increasing numbers of online users choosing to delete their facebook or google accounts.
If you want to use a third party login, remember to also provide a more traditional login option as well (email/username).
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.
So unless you have a very good reason to do something different, stick to login ids as email ids
Don't push your technical requirements onto the user when it's not needed.
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.
https://github.com/skorokithakis/django-tokenauth
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.
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.
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.
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.
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.
https://stackoverflow.com/questions/1303575/what-are-the-pro...
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.
Says someone who's "eternal" email address from a robust institution still very much a going concern, just went away.
Use the e-mail as the login locator, but not as the primary key.
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.
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).