Authentication, Roles and SSO for Business Apps

By Grocito13 October 2026

Authentication proves who a user is, authorisation decides what they may do, and single sign-on (SSO) lets them sign in once through a trusted identity provider. For business apps, use proven libraries or an identity service, add multi-factor authentication, give people only the access their role needs and keep audit logs of sensitive actions.

Key takeaways

Authentication answers "who are you?" and authorisation answers "what may you do?". Both must be designed, and they are not the same thing.
Never invent your own cryptography. Use well-tested libraries or an identity provider for password storage, tokens and login flows.
Multi-factor authentication stops most simple account takeovers and should be standard for admins.
Role-based access control and least privilege limit the damage when an account is misused or compromised.
Account recovery, audit logs, rate limiting and admin protections are as important as the login screen.

Authentication versus authorisation

Authentication is checking identity: the person logging in really is who they claim to be. Authorisation is checking permission: given who they are, are they allowed to view this invoice, approve this refund or change this setting?

Many security failures come from getting the second part wrong. An app can have a perfect login, yet if any signed-in user can open another user's record by changing a number in the address, the system is still unsafe. Check authorisation on the server for every request, never only by hiding buttons in the interface.

Passwords done safely

Passwords remain common, so handle them properly.

Never store passwords in plain text. Store only a salted hash made with a recommended, deliberately slow password hashing algorithm from a trusted library.
Never invent your own scheme for hashing, encryption or tokens. Use the proven, maintained tools provided by your framework or an identity service, and keep them updated.
Encourage long passphrases rather than complicated rules that people work around, and allow password managers to paste and fill.
Check new passwords against lists of commonly used or previously exposed passwords where practical.
Always use HTTPS so credentials are not sent in the clear.
Do not log passwords, and do not email them.

Multi-factor authentication

Multi-factor authentication (MFA) asks for something more than a password, such as a code from an authenticator app, a hardware security key or a passkey. Even if a password is stolen, the attacker is still stopped.

Options differ in strength and convenience. Authenticator apps and security keys are generally stronger than codes sent by text message, which can be intercepted in some cases. Make MFA mandatory for administrators and staff with access to sensitive data, and offer it to every other user. Provide safe backup options, so people are not locked out when they lose a phone.

Social login and single sign-on

Social and SSO login

Social login lets people sign in with an existing account from a large provider. SSO lets employees use their company account to reach many tools. Both reduce password fatigue and move part of the security burden to a specialised provider.

OAuth, OpenID Connect and SAML in plain terms

OAuth is a way for an app to receive limited permission to act on a user's behalf, without ever seeing their password. Think of it as a valet key rather than the master key.
OpenID Connect sits on top of OAuth and adds identity: it tells your app who has signed in. It is the modern choice for most new web and mobile apps.
SAML is an older, widely used standard for company SSO, common in larger organisations and enterprise software. Larger customers may request it by name.

You rarely implement these protocols yourself. Use a well-maintained library or an identity service, and follow its official documentation.

Role-based access control and least privilege

Role-based access control (RBAC) assigns permissions to roles, and roles to people. Instead of deciding access person by person, you define roles such as viewer, editor, manager and admin, and give each exactly the permissions it needs.

Least privilege is the guiding rule: people and systems should have the minimum access required to do their job, and no more. To apply it:

List the actions your app allows, such as view, create, edit, approve, export and delete.
Define a small number of roles that match real jobs.
Make the safe choice the default, so a new user starts with minimal access.
Review access when people change roles or leave.
Keep the highest-risk actions, such as exporting all data or changing billing, to few people.

If you serve multiple customer organisations, roles must also be tenant-aware, as described in our guide to multi-tenant SaaS architecture.

Sessions and tokens at a high level

After login, the app needs to remember the user. This is done with a session or a token that is sent with each request. Keep these principles in mind:

Generate them with trusted libraries, so they are long, random and hard to guess.
Set sensible expiry times and allow users to sign out and end other sessions.
Store them in ways that reduce theft by malicious scripts, and send them only over HTTPS.
End sessions when passwords change or accounts are disabled.
Treat any token as a secret, never put it in a web address and never log it.

The details are technical, so ask your developers to explain what is used and why.

Account recovery safety

Recovery is a favourite path for attackers, because it can bypass a strong password.

Send a time-limited, single-use reset link to the verified email address.
Do not reveal whether an email address has an account in error messages.
Notify the user by email when a password, email address or MFA setting changes.
For high-risk accounts, require extra verification before resetting MFA, and keep the process documented.
Train your support staff never to reset access based only on a phone call or message claiming urgency.

Audit logs

An audit log records who did what and when for sensitive actions: logins, failed logins, permission changes, data exports, deletions, setting changes and admin actions. It helps investigate incidents, answers customer questions and deters misuse. Store logs where they cannot be edited by the people they describe, keep them for a period that suits your needs and avoid putting passwords or secret tokens into them.

Admin protections and rate limiting

Keep the number of administrators small and require MFA for them.
Separate everyday accounts from administrative ones.
Add extra confirmation for dangerous actions, such as deleting an organisation or exporting everything.
Limit login attempts and slow down repeated failures, so attackers cannot guess endlessly.
Use temporary lockouts carefully, so attackers cannot easily lock out real users on purpose.
Watch for unusual sign-ins, such as many failures or sudden activity from a new place, and alert the right person.

Build or use an identity provider?

Building login yourself looks simple and becomes complicated: password hashing, resets, MFA, social login, SSO, session handling, brute-force protection and ongoing patches. An identity provider, or a mature open-source library, handles much of this and is kept up to date by specialists.

Building your own can be justified when you have unusual requirements, strict hosting rules or very large scale, but it should be a deliberate decision with security review. For most business apps, using a proven provider or library and focusing your effort on authorisation and the product itself is the safer route. Consider cost, data location, how easily you could switch later and what your enterprise customers expect. Our API services team can help you plan identity as part of a wider integration.

A checklist for vendors

When a vendor builds or reviews your app, ask them to confirm:

Passwords are hashed with a recommended algorithm through a trusted library.
MFA is available, and mandatory for administrators.
Login uses a maintained identity library or provider, with OpenID Connect or SAML where needed.
Permissions are enforced on the server for every request, using clear roles.
Sessions expire, can be ended and are protected in transit.
Recovery flows are safe and notify the user.
Audit logs exist for sensitive actions.
Login attempts are rate limited, and unusual activity is monitored.
Access can be reviewed and removed quickly when staff leave.
Security tests cover authentication and authorisation on every release.

Our website security checklist covers the surrounding basics.

A worked example

Imagine a small logistics company with a customer portal where clients track shipments. The first version has one shared admin login and every signed-in user can open any shipment by changing the number in the address. A safer redesign would use an identity library with MFA for staff, roles for clients, dispatchers and administrators, server-side checks that a client can only see their own shipments, rate limited logins, safe recovery emails and an audit log of exports and permission changes. Larger clients can later sign in through their own company accounts using SSO.

FAQ

What is the difference between authentication and authorisation?

Authentication confirms who someone is, usually with a password and a second factor. Authorisation decides what that person may do once inside. A secure app needs both, with authorisation checked on the server every time.

What is SSO and do I need it?

Single sign-on lets people use one trusted account to sign in to several apps. Small apps may not need it at first, but larger business customers often ask for it, so design your login in a way that can add it later.

How should an app store passwords?

It should never store the password itself. It should store a salted hash created with a recommended, slow hashing algorithm from a trusted library, and never invent its own method.

Should I build my own login system or use a provider?

For most business apps, use a proven identity provider or well-maintained library, since login is full of subtle security details. Build your own only when you have a clear reason and can afford proper security review.

Next steps

Write down who uses your app, what each type of user should be able to do and which actions are most sensitive. Check that MFA is on for administrators, that permissions are enforced on the server and that you have audit logs and a tested recovery process. If you want a review of your authentication design or help adding SSO and roles, contact us and we will go through it with you.