Identity, Authorization, Sessions, and Multi-Tenancy

Identity and authentication answer different questions

Identity is the subject the system knows about; authentication is the evidence used to establish that subject for this interaction. An email address is not proof of identity, and a valid password is not permission to perform every action. Keep external identity claims, local user records, organisation memberships, and service accounts distinct. Define how accounts are linked, renamed, disabled, and recovered. A provider subject identifier is usually more stable than a display email.

Use phishing-resistant authentication where practical, offer multifactor authentication for privileged roles, and protect recovery as strongly as login. Recovery links should be single-use, short-lived, and stored as digests. Administrative recovery needs explicit audit evidence and should not silently bypass tenant or role checks.

Authorisation must be evaluated at the resource boundary

A navigation menu is not an access control. Every protected action must verify the actor, organisation, role or capability, and ownership of the target object. Centralise reusable policy but keep the decision close enough to the resource that tenant scope cannot be forgotten. Query through organisation-scoped managers or explicit filters, and test that identifiers from another tenant return no usable data.

Roles describe broad responsibility; capabilities describe actions. Avoid a permanent administrator role that accumulates every new permission. Separate billing, support, deployment, content, and security duties. For high-risk actions, add step-up authentication, approval, or dual control. Record denied attempts as security signals without exposing whether a hidden resource exists.

Sessions are revocable security state

A session should have a secure cookie, bounded lifetime, rotation after authentication or privilege change, and server-side revocation. Protect against session fixation, cross-site request forgery, stolen cookies, and excessive concurrent sessions. Give users and administrators a way to invalidate sessions after password changes, device loss, staff departure, or suspected compromise. Remember-me behaviour should be deliberate and lower privilege where appropriate.

Do not place sensitive authorisation state only in a long-lived client token unless the system can revoke or re-evaluate it. Claims become stale when membership changes. For APIs, define token audience, issuer, scopes, expiry, key rotation, and service-to-service identity. Validate all of them rather than accepting any correctly signed token.

Tenant isolation is an invariant across every layer

Multi-tenancy affects URLs, queries, caches, files, queues, background jobs, metrics, exports, and support tools. Include tenant identity in cache keys and job payloads. Verify it again when a worker runs; do not trust a queued object identifier alone. Store uploads outside guessable public paths and authorise every download. Ensure logs and support screens do not mix customer data.

Test isolation adversarially. Create two organisations with similar data, attempt cross-tenant reads and writes through every public and staff route, and inspect exports, search, autocomplete, and background jobs. Review database indexes so tenant filters remain efficient. A single missing filter can defeat an otherwise sophisticated identity system.

Release review for identity authorization sessions and multi tenancy should name an owner, evidence location, review date, and the exact condition that would trigger a different decision. That record keeps the lesson tied to operational responsibility rather than leaving it as general advice. Teams should revisit the choice after incidents, major dependency changes, new data classes, or a material increase in scale.