User Login and Management: SSO, Two-Factor and Roles in a Business Application

The login screen is the first thing a user of a business application sees, and the last thing anyone remembers when writing the brief. In most projects it shows up as a single bullet point — "user login" — and the concrete decisions get made somewhere in the first week of development, without anyone consciously making them.

The problem is that these are the decisions that are hardest to change later. While the application is empty, switching the login approach is a matter of days. Once it holds two hundred accounts, their activity history and three integrations that reference those accounts, it becomes a project of its own, with a migration and downtime. This article walks through the three things that together make up user management: how a person signs in, how they prove it's really them, and what they're allowed to do once they're in.

Single sign-on (SSO) means the application has no passwords of its own — it delegates authentication to an identity provider the company already uses. In practice that tends to be Microsoft Entra ID (formerly Azure AD) or Google Workspace, sometimes Keycloak or another self-hosted option. The user clicks "Sign in with your company account", authenticates in the same place they authenticate for email, and comes back.

The difference isn't only convenience. With SSO, the company handles access in one place: when an employee leaves, switching off their company account removes their access to this application at the same time. With your own passwords, somebody has to know the application exists and deactivate the account there separately — and that is exactly what gets forgotten when people leave.

So the choice doesn't depend on what is "more modern", but on who the users are. An internal system for employees is a textbook candidate for SSO. A customer portal where people outside the company register cannot use it — they have no company identity. Plenty of applications therefore need both at once: SSO for the internal team and classic registration for external users.

Two-factor authentication (2FA, MFA) adds a second proof of identity on top of the password. The methods differ, though, in what they actually protect against.

• SMS code — the best known and the easiest for users to accept. It protects against an attacker who has only the password. It does not protect against a phone number being taken over at the carrier, nor against a phishing page collecting the code in real time.
• Authenticator app (Microsoft Authenticator, Google Authenticator, 1Password) — the code is generated on the device and never sent anywhere. The risk tied to the phone number disappears.
• Passkey / hardware key — authentication is bound to a specific domain, so a phishing page cannot abuse it even if the user opens one. It is also the only one of these methods that is faster for the user than a password.

For a business application the practical rule is simple: if you already use SSO, handle the second factor at the identity provider, not in the application. That is where the company has its policies, exceptions and account recovery set up — duplicating it in a single application means a second place where a change can be forgotten.

Login answers the question "who are you". Permissions answer "what are you allowed to do" — and that is the part where most real problems appear. Not because it is technically hard, but because it gets designed against the wrong criterion.

The most common mistake is deriving roles from the org chart: "director", "department head", "clerk". It sounds logical, but it doesn't work inside an application, because a job title says nothing about which data the person works with. The heads of two different departments need to see completely different things, and when a new position appears, nobody knows which role it belongs to.

A more workable approach is to derive roles from activities: who may view a record, who may edit it, who may approve it, and who may change system settings. Those four levels cover a surprising number of applications, and crucially they survive a reorganisation.

The second thing that gets underestimated is data scope. The role says what a person may do; the scope says what they may do it to. A salesperson may edit orders — but which ones? All of them, or only their own? Without an answer to that question you end up with a system where a technically correct role has access to the entire database.

These questions are worth answering in the brief, not during implementation:

1. Who are the users — employees only, external people only, or both? SSO follows from this.
2. Does the company have an identity provider, and who administers it? Without an answer, SSO can't be planned.
3. What activities exist over the main data — view, edit, approve, administer? Those are your candidate roles.
4. What is the scope for each role — everything, own records, the team's records, a specific branch?
5. How is an account created and closed — who does it, how do they find out they need to, and what happens to the data afterwards.
6. What has to be traceable — who signed in when, who changed what. An audit trail is very hard to add retroactively.

These questions get overlooked most in internal systems that replace spreadsheets and email — after all, nobody dealt with permissions in Excel. That's exactly why it pays to go through them before deciding on scope, something we also cover in our article on developing an internal company system.

User management isn't an isolated module. If the application talks to other systems, those systems need to know on whose behalf they are acting — a different problem from signing a person in through a browser. We look at how to design interfaces between systems in our article on API-first architecture.

Equally, anything that handles personal data ties directly into who has access to it and how that can be evidenced — we covered the practical side in our piece on processing personal data.

Choose SSO based on who your users are, not on what's fashionable — and if you deploy it, handle the second factor through it too. Design roles around activities rather than job titles, and give every role an explicit data scope. Check permissions on the server.

The scope of this part varies between projects more than you'd expect — it depends on the number of roles, on whether the company already has an identity provider, and on audit-trail requirements. If you're planning a new business application or reworking access in an existing one, we'll go through your specific requirements in a no-obligation consultation.