Making the security layer flexible
Today, I will be working on the new security layer.
Two key steps are required for this: introducing a new security system and migrating users from the old to the new system.
In the past, I have worked on account management multiple times, and a common mistake is to either oversimplify or overcomplicate the system. Oversimplification leads to inflexibility and significant limitations, while overcomplication results in excessive effort for development and maintenance.
Ultimately, the system must identify and authenticate users. The most prevalent solution today is a username and password, or an email and password combination. Email logging in is currently the most widely used because it ensures unique usernames and allows for immediate user contact, such as when they forget their password. Some providers even send a login link to the user’s email.
However, this is not the only method. I am also considering adding an anonymous option. This means users do not have a username or password. Implementing this is relatively straightforward by omitting input fields. When creating an anonymous account, users receive a random code that serves as both the password and the username.
I mention this option because it differs from the previous methods. While the other methods use a name and a code, the anonymous system only uses a code, creating a distinct paradigm. The advantage of the anonymous system extends beyond privacy. It also allows users to quickly create a temporary account to experiment without sharing personal information. In fact, if implemented effectively, users could try the application without realizing they have already created an account. Additionally, adding the ability to switch from anonymous to a regular account provides a seamless transition from a demo to a real user.
In the realm of account management, safeguarding the system is paramount. This encompasses implementing measures such as limiting login attempts, encrypting passwords, and restricting security tokens, among others. However, these are well-documented challenges, and as long as industry best practices are adhered to, they should not pose any significant issues.
Currently, our primary focus lies in designing the new layer. Our initial objective is to make Auth0.com (our current solution) a preferred choice, enabling us to introduce additional options in the future. However, before proceeding, we must revisit certain decisions made during the development of Todo2d.
