What if you don't have to build a login page again?

Muhammad Kholid B — Sun, 23 Aug 2026 15:18:15 +0000

How do you usually build a login page in an application?

The first project

Imagine you are working on a project that needs a login page. Let's call it Aurora (Project A). The login page is the entry point to the application. Users who have access can log in to the application with the permissions they have.

We are not going to talk about the details of the login method yet, such as email + password, username + password, phone + password, social login, magic link, or others. Let's say we use email + password for this example. For this, we usually need user data for the application, for example a users table in the database. If we use email and password as the login method, the users table would at least need email and password columns. Of course, the password should be hashed.

After the application is developed, users can log in using the email and password registered in the database.

During development, we can simply inject user data directly into the database. Adding one or two users manually is still fine. If we need more users, we can create a database script to insert them.

Then another requirement appears. We need to manage users directly from the application. Previously, user data could only be accessed directly from the database. Now the application needs to show a list of users, user details, and provide features to create, update, and delete users. We need to build several new pages for this user management feature.

Eventually, the feature is completed. Now you can add users whenever you want, and they can immediately use their account to log in to Aurora. At this point, the user requirements for Aurora might be enough.

The second project

Then you have another project that also needs a login page. Let's call it Borealis (Project B).

This is a different project from Aurora, but the login works in a similar way. Since you already built the login feature in the previous project, you can duplicate the existing code into Project B, including the user management feature. Now Project B not only has login, but also has user management just like Project A. You only need to change the styling to match Project B. The users table has the same structure, so you can simply copy the DDL and DML to the database of Project B. You feel this is more efficient than building the login and user management features from scratch again.

Then Project B is used by users.

Unfortunately, there is a bug in the login page that prevents users from logging in with an email containing uppercase characters. You fix the bug in Project B. But because the login and user management code in Project B was copied from Project A, the same bug also exists in Project A. So you have to fix it there too. You fix the bug in both projects and hope there will be no more bugs in the future, which is almost impossible.

The third project

Then a third project comes. Let's call it Chronos (Project C).

Just like the previous projects, this project also needs login and user management. You are still thinking about using the same code you already have in Project A and Project B. Eventually, you build the login and user management features in Project C. But then, there is a new requirement: users need to have roles that can be managed by an admin. For example, a user can have a role such as admin, user, guest, and so on. So you build a user role management feature in Project C.

Now the login feature that you originally built in Project A has grown into login, user, and role management. But this new role management feature only exists in Project C. You think about implementing it in Project A and Project B as well, but decide to do it later when there is actually a need for it. Project C is finally completed and ready to use.

At this point, you start thinking:

What if there are Project D, E, F, and more that need login and user role management?

You start seeing the same pattern in every new project you build. Of course, there will be different requirements depending on the project, but the basic needs for login and user management are still similar.

Are you going to keep copying the code from one project to another?

Is that really efficient?

Will you have the same bugs, or even new bugs, when copying the code?

And what happens when you need to maintain or update the login and user role management features later?

Do you have to update them one by one in every project?

What if the login and user role management features could be built once and used by multiple projects?

Two possible approaches

There are two approaches we can consider to handle this problem.

1. Create login and user management as a separate module/library

The module can then be imported into multiple projects.

Pros:

The code is built once and can be used by multiple projects.
It can be made modular, so each project can import only the modules it needs, such as login, user management, or role management.
Feature development only needs to be done once and can benefit all projects using the module.

Cons:

We need to carefully design the modularity.
A major change in the login and user management features may affect all projects using the module. This can be handled with module versioning.
Each project still needs to set up the database and data structure required by the modules.
What happens if different projects use different programming languages? How many programming languages do we want to support?

2. Create a separate application specifically for login and user management

Pros:

Projects that need login and user management can use the application directly without building them from scratch.
Projects do not need to worry about maintaining the login and user management features.
Projects can focus on their main features instead of spending time building login and user management.
There is no need to set up specific tables for user and role management in each project. Everything is handled by this application.
We do not need to support different programming languages. Projects can communicate with the login application through a communication protocol such as a REST API.
Feature development and maintenance are done in one place, so there is no duplicated code.

Cons:

The login and user role management application is separated from the main project, which adds some additional work when developing or maintaining the login application.
The system needs to be designed to support multiple projects and be as general as possible for any kind of project.

Considering development and maintenance efficiency, option 2 seems more interesting. We can focus on developing the login and user management features in one place without worrying about compatibility with other projects. At the same time, other projects do not need to worry about maintaining the login and user management features because they are already handled by the login application.

After looking into it further, it turns out that option 2 is not something new that we have to build from scratch. There are already several services that provide this kind of approach, such as Auth0, Firebase Authentication, Clerk, and others.

Some of these services are very complete and can be a good fit for certain use cases. They may even have more features than we actually need. But for the projects in our example above, we might need something more specific: login and user role management with the project as the main scope.

One of the services we built with this approach is Roled.

With Roled, authentication and user role management can be separated from the main application and managed through a single platform. Each application can have its own Project with isolated users, roles, resources, and permissions. The application does not need to worry about maintaining the login and user role management features because they are already handled by Roled.

Roled is not a centralized identity platform (IdP). It is a centralized user and role management platform, with authentication as one of its features. This means Roled can also be used together with an authentication system that an application already has.

Learn more about Roled and how to get started in the Quickstart.

We are currently looking for early adopters to experience the simplicity of Roled and become part of its development.

Try Roled and let us know about your experience!

Cover photo by Vasilis Caravitis on Unsplash.