Application security
App authentication and user account architecture
Sign-in is the visible part. The part that decides whether an application holds up is the account model beneath it: identity, session, membership and permission kept as separate concerns and enforced on the server.
Authentication looks like a solved problem from the outside: a sign-in form, a password field, perhaps a provider button. The parts that decide whether an application ages well are underneath — how identity, session, membership and permission are modelled, and where the decision about what a person may do is actually made.
Three concerns, not one
Most access problems come from collapsing these together — a session that implies a permission, or a profile field that doubles as a role. Kept separate, each one can change without disturbing the others.
Identity, session and permission
Choosing an authentication model
The right model follows from who is signing in and what the account can reach, not from what is fashionable.
Choosing an authentication model
| Context | Sensible default | Watch for |
|---|---|---|
| Consumer product | Email plus provider sign-in, optional second factor | Account recovery is the real support cost, not sign-in |
| Business team product | Organisation accounts, invitations, roles per organisation | Offboarding, seat transfer and orphaned admin accounts |
| Internal or regulated | Single sign-on with enforced second factor | Central revocation and a usable audit trail |
| Public marketplace | Light sign-up, verification before privileged actions | Claiming and ownership disputes over existing records |
Permissions are a server concern
Hiding a button is a usability decision. It is not a security control. Every protected action needs an authorisation check on the server, against the account making the request and the specific record being touched — not against a role fetched once and cached in the browser.
- Roles in a dedicated table, read server-side, never trusted from the client.
- Record-level checks, not just route-level ones: the right role on the wrong organisation's data is still a breach.
- Deny by default, so a new endpoint is inaccessible until someone deliberately opens it.
- An audit trail for privileged actions — who changed what, when, and on whose behalf.
The parts teams underestimate
Account recovery, email change, session revocation, invitation expiry and administrator transfer generate more support work than sign-in ever does. They are part of the account architecture, not an afterthought bolted on when the first support ticket arrives.
Where an application also exchanges data with other systems, the same discipline applies to machine access: scoped credentials, rotation and least privilege, as covered in APIs and integrations in modern applications. If you are planning an authenticated product, this is one of the first decisions we work through in application and PWA development.
An interface can only hide options. If the server does not check, the option was never really hidden.
Frequently asked questions
- What is the difference between authentication and authorisation?
Authentication establishes identity — this request comes from this account. Authorisation establishes rights — this account may perform this action on this record. They are separate systems and should be reasoned about separately.
- Where should user roles be stored?
In a dedicated roles table linked to the account, read by the server on every protected action. Storing a role on the profile record or in local storage lets a determined user grant themselves privileges, which is a straightforward privilege escalation.
- Do I need social or provider sign-in?
For consumer products it usually reduces friction and support load noticeably. For internal and regulated products, centralised single sign-on with enforced second factors matters more than convenience.
- How long should a session last?
As long as the risk profile allows. A field application used on a shared device warrants short sessions and quick re-authentication; a personal productivity tool can hold a session for weeks. Whatever the length, revocation has to work immediately.
- What about team and organisation accounts?
Model membership explicitly: an account belongs to one or more organisations, with a role in each. Products that treat a business customer as a single shared login run into seat management, offboarding and audit problems within months.
- Is two-factor authentication necessary?
Offer it everywhere and require it wherever an account can move money, change permissions or reach personal data. The cost of enabling it is small next to the cost of one compromised administrator account.