Users

It's pretty rare to stumble upon a web site that doesn't invite you to register or subscribe to something.
Most, if not all, web sites out there hold some sort of user information, ranging from just an email address to send you updates, promotions, etc. to complete-if-you're-for-it social sites asking one the most intimate piece of information about one's life.

I lay down here some thoughts on how to design user information at a high level.

User? Client? Customer?

There's quite a bit of debate on what to call those people using one's site. Some people find "user" too abstract, yet I find it powerful and having a software engineering background, abstraction is my (professional) life. So I'll stick to user, ne vous déplaise.

Concerns

There are so many things that can be stored about a user. I try to categorize those so that, even if missing, a new piece of information might either fall within those categories, or just be part/extension of an existing entity.
Ultimately the goal is the same as in most aspects in software engineering: separation of concerns.

Fig. 1. User Information

Users

The core concept behind defining user information is to identify the user. The identifier (id) is commonly used when create a User class for instance but other bits of information should be stored along to simplify basic logic within the application. Whether the user is coming from a Google Sign In or Facebook Sign In, one needs to uniquely identify the same user within his application.
The confirmation (confirmed) for instance that the user is indeed a user (vs. spam), or that the user (account) has been locked/disabled/enabled (disabled), to prevent one to log in or to access more privileged features (e.g. membership expired or revoked).
There could be more information stored here but the idea stands it should be limited to basic application logic and more intrinsic, rarely-changing, information.
My dream travel destination my change over time, but my first, middle and last names are less likely to change.

It may not be obvious but having credentials information here is "risky". This core information can be queried quite often, be it to get non-disabled-user content, to display "Hi Mr. Pezet!" or other kind of front-end gizmo, all of which could be cached, stored in session or even logged...but if the password field is in there somewhere, this could be a security risk.

Authorization

This governs the capability of authorizing (or not) access to features or content on one's site.
There's a lot to talk about when it comes to authorization but it's enough to know that, the information stored will vary upon the approach and implementation chosen.
A role-based authorization (aka RBAC) will mostly store roles, whereas a rule-based authorization will deal with subjects, operations and objects.

Subscriptions

This is mostly for notifications to the user, by email or SMS for example, when something of interest happened. It could be a new promotion, new event, new piece of content, etc.
It's not uncommon that this piece is provided by/outsourced to a third party (e.g. iContact), as it involves quite a bit of work for such basic feature.
This includes processing bounced emails, spam notifications, un-subscriptions callbacks and requests, etc.

Profiles & Accounts

Any extrinsic, most-likely-to-change-or-be-missing, information should be handled separately from the "User" entity.
Profile and such entities are a great way to store those bits of data and the absence of it should not affect the application operation.

Some applications might have users share the same account, like in Netflix for example. In this case, an Account entity is well suited to store whatever is common between users sharing the same account.

Authentication & Security

In order to authenticate a user, certain bits of information need to be collected.
Even when coming from say Facebook, the application will need to store tokens and other pieces of information to identify the user later on.
If the application is not using a delegated authentication, then username/password and other such information will need to be stored.
If the application also provides "remember me" functionality, then more information is needed.

In some more advanced security features, tracking might be put in place to help further secure access to the application and its content. This include password history, (IP/geo) location history, device history, etc.

User Content

Videos, reviews, posts, documents, anything contributed by or belonging to the user. Some may not even have content, in which case this separate piece of information will not be present in such application.

To be continued

I laid out some of the basic information gravitating around a user. Each application is unique, but most likely using or extending some of the entities I mentioned here.

There's a lot more to talk about when it comes to  authentication and authorization. Some of the logic is universal (e.g. password policies, rules vs. roles, etc.) and yet it's often very unclear on how to tackle those exactly.