In short
Web-app authentication should use a mature identity service or carefully maintained framework, then design the complete lifecycle: enrollment, verification, sessions, recovery, multi-factor options, identity linking, revocation, support, and audit. Authentication proves identity; authorization must separately enforce what that identity may do on the server.
Authentication is not authorization
Authentication answers who the user is. Authorization answers whether that identity may read or change a specific resource.
Hiding a button is not authorization. Enforce access on the server for every protected operation and test negative cases between roles and tenants.
Decide the identity model
- email and password;
- magic link or one-time code;
- social identity;
- enterprise single sign-on;
- passkeys;
- invited organization accounts;
- anonymous-to-registered transition.
Choose for user context, risk, device, support burden, and customer requirements. Avoid collecting passwords when a mature identity provider can own the hardest parts safely.
Design the complete lifecycle
Enrollment
Who can create an account, invite users, choose an organization, and verify identity? Prevent invitation leakage and account enumeration.
Sessions
Define duration, refresh, device handling, inactivity, sensitive-action reauthentication, logout, and server-side revocation.
Recovery
Recovery is an alternate authentication path and often the weakest one. Design expired tokens, changed email, lost MFA device, compromised account, and support verification.
Identity linking
The same email arriving through password, Google, and company SSO can create duplicate or takeover risk. Define when identities merge and require proof.
Role and tenant changes
Access must change promptly when a user leaves, moves teams, loses a role, or an organization ends its contract.
Deletion and retention
Separate account access, profile deletion, business records, audit needs, backups, and legal obligations with qualified privacy guidance.
Build a permission matrix
| Resource/action | Member | Manager | Admin |
|---|---|---|---|
| View own records | Yes | Yes | Yes |
| View team records | No | Yes | Yes |
| Change billing | No | No | Yes |
| Remove organization | No | No | Restricted admin flow |
Add ownership, status, region, and tenant conditions. Test every “no”, not only successful access.
Support without creating a back door
Support staff need a defined, logged process. Avoid shared administrator accounts and casual impersonation. Use time-bounded access, reason capture, approvals where consequence is high, and clear user communication.
Operational requirements
- rate limiting and abuse detection;
- audit logs and alerting;
- secret and key rotation;
- provider outage behaviour;
- backup administrator access;
- incident and revocation process;
- privacy-safe logs;
- test accounts and environments.
Common questions
Should we build authentication ourselves?
Usually not from primitives. Use a mature provider or maintained framework unless specialised requirements and qualified security capacity justify ownership.
Are magic links more secure than passwords?
They remove password storage and reuse but depend on email security and link handling. Suitability depends on threat model, user context, and recovery.
Does every app need MFA?
Risk, data, roles, and customer requirements determine it. Offer or require stronger factors for administrators and high-consequence actions where appropriate.
How long should sessions last?
Balance user context and consequence. Use shorter or renewed authentication for sensitive actions and ensure sessions can be revoked.
What is tenant isolation?
It prevents one customer organization from accessing another's data. Enforce it in server-side data access and test cross-tenant requests explicitly.
