How to Build a Multi-User Web Application for Your Organization

Building a multi-user web application for an organisation comes down to five foundations: reliable authentication (proving who someone is), role-based access control (deciding what they may do), secure sessions, audit logs that record who changed what, and a clear lifecycle for creating, changing and removing accounts. Get these right first and every feature built on top inherits them. Tarka Raj Jaishi, a full-stack developer in Lamki, Kailali, Nepal with a cybersecurity background, explains each foundation below with practical examples.

A single-user tool only has to protect itself from outsiders. A multi-user application must also protect users from each other: the receptionist should not see salaries, a branch in Tikapur should not edit a branch in Dhangadhi's stock, and a former employee should lose access the day they leave. Many internal data problems are not dramatic hacks at all; they come from ordinary accounts with more access than they needed.

Authentication answers "who are you?" Good practice includes:

• Passwords stored only as strong one-way hashes (using algorithms such as Argon2 or bcrypt), so even a database leak does not reveal them.
• Rate limiting and lockouts after repeated failed attempts, to stop automated guessing.
• Secure password reset through a time-limited link or code, never by emailing the password.
• Optional two-factor authentication for administrators and anyone handling money.
• Login options that suit staff: many organisations in Nepal prefer phone numbers to email addresses, since not every staff member uses email regularly.

For organisations that already use Google Workspace or similar, single sign-on can let staff log in with their existing work account.

Authorisation answers "what are you allowed to do?" Rather than setting permissions person by person, RBAC groups permissions into roles, then assigns roles to people. When someone changes job, you change their role, not dozens of settings.

Here is an example for a cooperative with several service centres:

1. Least privilege: give each role the minimum it needs. Add more later if required.
2. Enforce on the server: hiding a button is not security. Every request must be checked on the server, because anyone can craft a request directly.
3. Scope by data, not just action: "can approve loans" must also mean "only in their branch" and "only up to their limit".
4. Separation of duties: the person who creates a payment should not be the only person who approves it.
5. Keep roles few and named after real jobs, so managers understand them.

After login, a session keeps the user signed in. Done carelessly, sessions are an easy way in for attackers.

• Store session tokens in secure, HTTP-only cookies so scripts on the page cannot read them.
• Expire idle sessions, with shorter limits for sensitive roles. A shared counter PC left logged in is a real risk.
• Let users see and end their active sessions, for example after losing a phone.
• End all sessions immediately when a password is changed or an account is disabled.
• Protect forms against cross-site request forgery so another website cannot submit actions as the user.

An audit log is a permanent record of important actions. When a stock count is wrong or a payment is disputed, it turns an argument into a lookup. Record at least:

• Who performed the action and from which account.
• What changed, including the old and new values for important fields.
• When it happened, with a reliable server timestamp.
• Where relevant, the branch and device or IP address.

Log logins, failed logins, permission changes, financial edits, deletions and data exports. Audit records should be append-only: ordinary users, and ideally not even admins, should be able to edit them. Tarka's own site, tarkarajjaishi.com.np, runs on Next.js and PostgreSQL with accounts, comments and an admin panel, the same kind of foundation described here.

1. Creation: an admin invites the user with a specific role; the user sets their own password through a one-time link.
2. Onboarding: the user confirms their details and, for sensitive roles, enables two-factor login.
3. Role changes: promotions or transfers update roles, and the change is logged.
4. Periodic review: managers confirm their staff's access is still correct.
5. Suspension: temporary leave can pause access without losing history.
6. Deactivation: when someone leaves, the account is disabled and sessions ended immediately. Avoid deleting accounts outright, because their past actions must remain traceable in records and audit logs.

Before development, write down every job title that will use the system, what each one does daily, what they must never see, and which actions need approval from someone else. That list becomes your roles table. For the security practices that surround these features, read building fast, secure and scalable web applications. If your organisation has several locations, multi-branch business management software covers branch-level data separation, and if you plan to sell your system to other organisations, the guide to SaaS development covers multi-tenancy.

Authentication confirms who a user is, usually through a password and possibly a second factor. Authorisation decides what that confirmed user is allowed to see and do. A system needs both to be secure.

Yes. In small organisations one person often wears several hats, for example manager and cashier. The system can combine permissions from several roles, though separation-of-duties rules may still block certain combinations.

Disable them instead. Disabling removes access immediately while keeping the history of what that person did, which you may need for audits or disputes.

They settle questions quickly, such as who edited an invoice or who approved a discount. They also discourage misuse, since staff know actions are recorded.

Yes, if that suits your staff. Phone-based login with a one-time code or password works well where email is not used regularly, though it should be paired with proper rate limiting.

If your organisation needs a system where many people work safely with the right access, Tarka can help you map roles and permissions before any code is written.

• Phone: 9865760285 / 9812636744
• WhatsApp: +977 9865760285
• Website: tarkarajjaishi.com.np
• Facebook: facebook.com/TarkarajJaishi