LinkedIn and Facebook can do this because your email is not your username. There likely isn't really a username in those systems, just a user id. Almost all systems have a user id, but the distinction here is slightly different. Instead of a user record which has an id, username and possibly full name, Facebook likely has a user record with an id, a (display) username, and then there is a separate set of auth records with the multiple ways you can authenticate to the account, such as emails and passwords, API tokens, phone numbers, etc.
It may not sound like a big distinction, but there is a big distinction there. Instead of your username being your email address, they've abstracted the authentication from the core user record such that usernames are not used for authentication, so don't have to mutate if the authentication identifier (email address, phone number) changes, just some auth settings. This is obviously a much more extensible and robust way to deal with authentication over time, but it's also obvious it's much more complex than a simple username/password pair.
For the most part. My example was more a bipartite pattern, because I was covering the authentication aspects, not the entire identity structure (which I believe Facebook and LinkedIn would implement as the article outlines). For a system where you don't need to track multiple social identities, and where you interact within that system through your identity on that system, that's probably enough.
Yea maybe I should've been more specific but I was just talking about the user's perspective: usernames aren't necessary for most sites and just means one more thing they have to create and remember.
Re: implementation - I don't see the big distinction. These are all just related properties of a master user id number. Those properties can be anything and any of them (in any combination) can be used to login.
What you're describing is "use a synthetic primary key for your User", which is something even the most naive junior web developer does automatically these days. There's nothing special about LinkedIn and Facebook except that they went through the trouble of adding additional authentication mechanisms. You can too, no matter what you treat as a "username".
I'm not entirely sure where you got the impression I was implying it was hard and esoteric, and only Facebook and LinkedIn could do so. I was simply noting that there's a difference between email as a username and email as part of one or more authentication tokens, and the differences in design and how it affects the possible future need of users to change what are often usable as authentication (email addresses, phone numbers, etc).
It may not sound like a big distinction, but there is a big distinction there. Instead of your username being your email address, they've abstracted the authentication from the core user record such that usernames are not used for authentication, so don't have to mutate if the authentication identifier (email address, phone number) changes, just some auth settings. This is obviously a much more extensible and robust way to deal with authentication over time, but it's also obvious it's much more complex than a simple username/password pair.