For some time now I have the feeling the user entity is misused in code.
After having a eureka moment I can pinpoint the problem.
What is the user entity?
The most broad definition for me is an entity that interacts with the application. An entity for me is something or someone that is identifiable.
Being identifiable does mean there are one or more properties that make the entity unique. humans have unique fingerprints, whales have a unique tail, a server has an IP, a bot has a user agent, and so on.
A person can also have a passport from a country or an email address. So an entity can be identifiable in multiple ways.
What is the problem?
As long that the application doesn't have those properties the entity is anonymous.
Most applications limit functionality based on the authentication state. And here is where it gets messy.
The user has to add their identification to the application. And because most identifications can be stolen, applications add at least one other form of identification. Basically this is two factor identification.
For a long time the second form of identification was and is done by a password. That is why in a lot of applications a password field has become a default field for a user entity.
But now we have a lot more options like using a one time link, a one time password, a security key, an authenticator app.
And now we come to the problem. The two factor identification most people know is actually a multi factor identification because developers left in the password identification and added the two factor identification method on top of that. This is not a good user experience.
Or when an another form of identification is added the password identification is left in place. We know passwords are a security risk because phishing, man in the middle attacks, rainbow table attacks, and more of that fun stuff.
Solution
When designing an application think twice before adding a password field to the user entity. If it is a default of the used framework, remove it if you don't need it.
Even think twice to make sure the application needs a user entity. Maybe it needs a human entity and a server entity. That way the properties are more context bound.
Think about how the app provides the least annoying authentication for the targeted public without sacrificing security.
Top comments (0)