User Management – User's blog

Introduction – User Management, or Who Has the Keys to Your Digital Kitchen?

Even if your code is flawless, has passed all unit tests, and linters can’t find a single unnecessary space in it, your application can still become a source of problems. Why? Because technical correctness is only half the battle — the other half is controlling who you give those tools to.

Imagine a situation where one user of your application suddenly deletes another user’s signature recipe, and a newly registered guest changes the configuration of the entire system. Total chaos – Why? Because a solid permissions management system was missing.

Access management is like being a restaurant manager — you decide who enters the dining room, who can access restricted areas, and who gets the keys to the pantry. Whether you’re building a small app or a massive enterprise system, you need to implement bulletproof doors and a logical permission-granting mechanism. In this chapter, you’ll learn how to build a system that survives any kitchen revolution.

Authentication vs. Authorization

Before you start writing complex management systems, you need to understand two fundamental, entirely different processes that always follow each other in a strictly defined order:

Authentication: Who are you?

Authentication is the process of verifying identity. A guest approaching the door of your application must prove who they are — for example, by providing an email and password. Additionally, 2FA verification can be added, such as sending an access code to an email address. The OAuth2 protocol is also widely implemented, allowing users to log into the application via their Google or GitHub account —this way, your system never handles user passwords directly, but simply receives a token confirming identity. Only when the credentials match do the doors open just enough to let them in.

Important rule: Passwords are “perishable products” — never store them in plain text! The system should only store password hashes. This way, even if someone breaks into the database, they won’t learn the user’s real password.

Authorization: What are you allowed to do?

Only after identity is confirmed does Authorization come into play — determining: “What are you allowed to do in this kitchen?” This separation is essential for maintaining system integrity. Just as in three-tier architecture we separate the frontend from business logic, in user management we must separate being logged in from having specific permissions.

Note: Authentication always happens first. You first ask who someone is, and only then decide what they can do.

The Chef’s Four Basic Tools (Permissions)

Before users can access the system, we need to establish which tools we’ll hand them. In software engineering, permissions typically come down to four fundamental actions (known as CRUD):

Read: Viewing a recipe. A guest can enter, read the ingredients, but won’t change anything.
Write: Allows creating a brand new recipe from scratch and adding it to the database.
Edit: Enables updating and correcting what already exists (e.g., changing the amount of flour in a recipe).
Delete: The final decision. The recipe disappears forever. This tool, like the sharpest knife in the kitchen, should only be granted to highly trusted users.

Challenging Assumptions: How to Organize the Staff?

Beginner app developers assume that two types of users are enough: “Admin” (who can do everything) and “Regular User” (who can do very little). We’ll quickly challenge this assumption. As an application grows, such a division is insufficient and leads to the creation of so-called “spaghetti code” full of conditionals. The industry uses well-tested models instead.

RBAC (Role-Based Access Control) — the job title system

This is the most popular approach. Instead of assigning permissions to each person individually, we create roles and assign them to users.

Head Chef role (Administrator): Has the key to every cabinet, can manage staff and delete any content.

Chef role (Editor): Has access to the countertops and spices; can create and update recipes, but cannot permanently delete them from the menu.

Guest role (Reader): Has access only to the dining room: can browse the menu, but has no access to the back of house.

This approach is incredibly scalable. When your application grows to the size of a “culinary empire,” you don’t have to program permissions for every new user individually — you simply assign them to an existing role.

ABAC (Attribute-Based Access Control) — tailored access

But what if you want a user to be able to delete a recipe, but only the one they created themselves? RBAC fails here, because an “Editor” could delete everything. This is where ABAC comes in. In this model, access depends on attributes: who you are, what you want to do, and what the conditions are.

The system checks: Does the recipe’s author ID match the ID of the currently logged-in user? If yes — the “Delete” button becomes active. This provides a high degree of flexibility.

ACL (Access Control Lists) — the guest list

If your cookbook is meant to work like Google Docs, where you share a specific item only with selected people, you’ll use Access Control Lists (ACL). Each recipe has its own private guest list with assigned rights (e.g., Alice can edit, Bob can only read).

Entry Tickets: How the System Recognizes Users

The application needs some way to “remember” that you’re logged in as you move between screens. Modern systems do this using tokens — special digital documents that the application sends in the background:

ID Token (Identifier): Answers the question “Who are you?” It contains your name, role, and email, used so the kitchen knows who has crossed the threshold.

Access Token (Key to the pantry): This is what tells the server what you’re allowed to do and is checked with every click you make. It is issued for a short period of time, which increases security.

The Chef’s Good Advice: Security Principles

Summarizing the development of our application at this stage, you must implement several key practices to avoid creating automated chaos:

Principle of Least Privilege (PoLP): Every user should receive the absolute minimum permissions needed to perform their task. If someone is only supposed to cook from your recipes, don’t give them editing permissions!

Keep it simple: Don’t create hundreds of complex roles if at the current stage you only need two.

Audit access: People leave and change their interests. Regularly check that no one has retained access they no longer need (so-called permission creep).

Summary

Our product has seen tremendous growth! We’ve built a logical user management system. We’ve configured roles, secured the application against unauthorized access, and allowed people to collaborate safely. Our digital cookbook is no longer just a private notebook, but a secure platform for many people.

However, even the most perfect permission system won’t protect us from one thing: hardware failure or an accidental bug in the code that corrupts our data. Now that we’re sure only trusted guests enter our kitchen, it’s time to make sure their precious recipes never disappear — even if the entire building suddenly disappears completely. Let’s therefore move on to the topic of backups, or how to build a digital safe that survives any storm.

Materials

Self-study materials that are related to this topic: