Authentication confirms who a user is; roles and permissions decide what that user can do. For most new web apps, the sensible path is a proven authentication service or library, email login with optional two-factor, three or four simple roles enforced on the server, and an audit trail. Custom-built login code is where many serious security mistakes begin.
What is the difference between authentication and authorisation?
Authentication answers "who are you?"; authorisation answers "what are you allowed to do?" They are separate systems, and confusing them causes real bugs.
- Authentication happens at login. The user proves their identity with a password, an emailed link, a fingerprint, a Google account or a company single sign-on.
- Authorisation happens on every action afterwards. Can this user see this invoice? Edit this project? Delete this account?
A common failure is getting authentication right and authorisation wrong: everyone logs in securely, but any logged-in user can open another customer's records by changing a number in the web address. Every request must check both who the user is and whether they may access that specific record.
Which login methods should your app offer?
Start with one or two methods that suit your users, and add others when customers ask. Each option has costs in build effort, support and security.
| Method | How it works | Pros | Cons | When to offer |
|---|---|---|---|---|
| Email and password | User sets a password | Familiar, works everywhere | Weak or reused passwords, reset support | Almost always, at launch |
| Magic link | One-time login link sent by email | No password to forget | Depends on email arriving quickly | Occasional-use apps, portals |
| Social login | Sign in with Google, Apple or Microsoft | Fast sign-up, fewer passwords | Ties users to another provider | Consumer and small-business apps |
| Two-factor authentication (2FA) | A second check via an app code or passkey | Blocks most stolen-password attacks | Slightly more friction | Offer at launch, require for admins |
| Passkeys | Device-based login using fingerprint, face or PIN | Strong and phishing-resistant | Newer; users need guidance | Worth offering as support matures |
| Single sign-on (SSO) | Login through the customer's company identity system | Required by many large companies | More set-up per customer | When enterprise deals need it |
Admin and staff accounts should always require two-factor authentication, even if it is optional for customers. These accounts have the most power and are the most attractive targets.
Should you build authentication yourself or use a service?
Use a well-established authentication service or framework library unless you have a strong reason not to. Login looks simple, but secure password storage, session handling, account recovery, rate limiting and token management are full of subtle traps.
Your options:
- Hosted authentication services, such as Auth0, Clerk, AWS Cognito, Firebase Authentication or Supabase Auth. Fast to integrate, handle security updates for you, usually priced by monthly active users.
- Framework-built-in authentication in mature web frameworks. No per-user fees, well tested, but your team maintains it.
- Fully custom code. Rarely justified for a new product.
The trade-off is cost and control versus effort and risk. Hosted services can become expensive at large user volumes, and moving away later means migrating users. Framework libraries keep data in your own database but need more care. Either is far safer than writing password handling from scratch.
How should you design user roles?
Start with the fewest roles that reflect real differences in what people do, and enforce them on the server. Three or four roles cover most early products.
A typical starting set for a B2B web app:
- Owner — manages billing, settings and team members; one or two per company.
- Admin — manages users and most settings, but not billing.
- Member — does the day-to-day work.
- Viewer — read-only access, often for clients, auditors or managers.
Then define permissions per role as specific actions, such as "create invoice", "export data" or "invite user", rather than writing checks like "if user is admin" throughout the code. That makes it much easier to add a role later without hunting through the whole system.
Roles must also respect company boundaries. An admin at Company A must never manage users at Company B. This is where roles connect to multi-tenant design, which we explain in our guide to multi-tenant SaaS architecture. For a deeper look at permission design in business systems, see our explainer on how permission design works in business systems.
What security basics are non-negotiable?
A handful of controls prevent most account-related incidents, and none of them are optional. Ask your developer to confirm each one:
- Passwords stored with a slow, modern hashing algorithm such as bcrypt or Argon2, never in plain text or with fast hashes.
- Login rate limiting and lockout, so attackers can't guess passwords endlessly.
- Secure sessions, with cookies marked secure and HTTP-only, sensible expiry and logout that actually ends the session.
- Safe password reset, with single-use, expiring links that don't reveal whether an email address is registered.
- Server-side permission checks on every request, not just hidden buttons in the interface.
- Audit logs of logins, failed attempts, role changes and sensitive actions.
- Two-factor authentication available to all users and required for staff.
The OWASP project's guidance on authentication is a good, vendor-neutral reference to share with your team.
What does a real authentication flaw look like?
Real flaws are usually small configuration details, not dramatic hacks. We found one on our own site.
During a security review of grww.tech, we discovered that the login rate limit could be bypassed. The limit was applied per IP address, but the code read the visitor's IP from a request header that a client could set to anything. An attacker could change that header on each attempt and appear to be a new visitor every time, avoiding the limit entirely. We fixed it by trusting only the IP address supplied by our own server infrastructure. In the same review we removed unsafe-eval from the site's Content Security Policy, a browser security setting that limits what scripts can run.
The lesson for founders: security controls need testing, not just implementing. A rate limit that exists in code but can be bypassed provides false comfort. Include login protections in every security review.
How do roles show up in your admin tools?
Your internal team needs roles too, often more carefully than customers do. Staff accounts can usually see every customer, so a support agent shouldn't automatically have the power to issue refunds or export all data.
Keep internal roles separate from customer roles, log every staff action, and put sensitive powers like impersonation and bulk export behind specific permissions. Our checklist for what a good admin dashboard includes covers the internal side in detail.
Data-protection laws in your markets, whether that is the DPDP Act 2023 in India, the Privacy Act 1988 in Australia or GDPR in Europe, expect reasonable security for personal data. Tight access controls and audit logs are a practical part of meeting that expectation.
Login and roles are early, foundational pieces of the SaaS build roadmap we use with founders.
Frequently asked questions
Do I need two-factor authentication in my MVP?
Offer it to users and require it for staff and admin accounts from day one. Most hosted authentication services make it straightforward to add. Larger customers increasingly ask about it during procurement.
Is "Sign in with Google" enough on its own?
For some consumer or small-business apps, it can be the main method. Most products also offer email login, because not every user has or wants to use a Google account. Business buyers may later require their own SSO.
How many user roles should a new app have?
Usually three or four, such as owner, admin, member and viewer. Add more only when customers show a real need. Too many roles early on confuse users and make permissions harder to test.
When do I need single sign-on (SSO)?
When you start selling to larger organisations that manage staff accounts centrally. Many SaaS products include SSO in their top pricing tier because enterprise customers expect it and it requires extra set-up for each one.
What happens if a user's account is compromised?
You should be able to end all their active sessions, force a password reset, review their recent activity in the audit log and notify them. Plan these tools before launch. Depending on the data involved, privacy laws may also require you to notify affected people or regulators.
Building login and roles you can trust
Authentication and roles are invisible when they work and very visible when they fail. We build secure login, role design and audit logging into the web apps and SaaS products we deliver through our custom software services. If you want a second pair of eyes on your app's access model, arrange a review or a fixed-price build quote.