Key concepts

The records to keep apart: the person, the organization (tenant, workspace or account, depending on the product), the membership linking them with a role, the connection to that organization's directory, each credential (password, passkey, authenticator seed, recovery codes), each session and token, and each non-human identity: service accounts, registered OAuth clients, API keys and agents. One human often holds several identities, such as a work login through SSO, a personal Google login and an old password account at the same domain.

Key every identity on a stable ID from its source: issuer plus subject in OpenID Connect, issuer plus name ID in SAML, the directory's external ID in SCIM. Email changes and gets recycled, and linking accounts because emails match is how attackers set up a takeover before the real user signs up.

Most B2B apps use one global pool of users with memberships (the Slack and GitHub shape), so a person can belong to several organizations; separate pools per customer isolate harder and cost more to run.

An account goes invited, active, suspended, deactivated and deleted, sometimes reactivated. A credential is enrolled, verified and revoked; a session is created, refreshed, then expires or is revoked; an enterprise connection goes draft, verified, active and disabled. SCIM moves users through create, update and deactivate, and real directories rarely delete.

The state most systems lack is "decommissioned": tokens, keys and test accounts nobody switched off. Microsoft's Midnight Blizzard breach in 2023-24 started with a password spray on a legacy test account with no MFA, then used an old test OAuth app with high privileges.

Timers define behaviour. NIST's 2025 guidelines suggest ending sessions at the middle assurance level after 24 hours, or one hour idle, and disabling an authenticator after at most 100 failed attempts in a row. Access tokens live minutes and refresh tokens days to months.

For enterprise users the app owns fewer facts than its database suggests.

Google's Zanzibar paper treats stored relationships ("Ana is an editor of board 42") as the ledger of access, with a consistency token so a permission removed a second ago isn't missed by a stale read; Google reported over 2 trillion stored permissions and millions of checks a second.

The audit log is the record investigators read. Okta missed file downloads in its 2023 support-system breach for about 14 days because two ways of viewing a file wrote different log events. I'd treat sign-in events (success, failure, factor used, recovery, admin resets) as a record customers can read and export.

Permission models come in three families, usually mixed. Roles are simple and auditable until every customer wants a custom one ("role explosion"). Attribute rules (department, region, time) are flexible and hard to explain to an auditor. Relationships handle sharing, folders and nested teams, and need a store and modelling skill.

Where the check runs matters as much as the model. The gateway confirms a token is valid and has the right scope, the service decides whether this user may do this to this record, row-level security in the database filters by tenant as a last line of defence, and hiding a button controls nothing. OWASP's advice: deny by default, implement the check once and reuse it, enforce record ownership, and log failures.

OAuth scopes record consent for an app. A token with "files:read" says what the app may do for the user; the app still has to check what the user may do, and agents widen that gap. The other rules are customers' settings (require SSO for our domain, MFA for everyone, sessions under eight hours, these IP ranges only), which belong in the product as per-organization policy that admins set themselves.

Dates I'd keep on a calendar as of October 2026:

Inside the product, dates sit on SAML certificates, token lifetimes, invitations, recovery codes and the gap between someone's last day and the moment the app learns of it. A questionnaire written in 2026 may still ask for 8-character passwords with complexity rules NIST dropped in 2025, so ask which version a requirement comes from.

The mature standards cover sign-in and provisioning; the ones for machines, agents and authorization are newer, and several are drafts (the MCP specification still cites version 13 of the OAuth 2.1 draft while the IETF is on 16). SCIM says nothing about revoking sessions, which is the gap behind lingering access, and SAML's XML signature layer, where the ruby-saml bugs sat, is the riskiest part to build.

Login runs on federation, trust between systems that don't share a database. Customers' directories (Okta, Entra, Google Workspace) decide how enterprise users arrive and leave, and their quirks set your support load. Credential managers (Apple, Google, Microsoft, 1Password) hold passkeys. Phone carriers and email providers carry codes and reset links, so their weaknesses become yours. Outsourced help desks reset accounts on someone's behalf and are a favourite target: Marks and Spencer's 2025 breach and Clorox's suit against Cognizant both centre on one. Insurers write rules through the MFA questions on their applications.

The trust anchors are concrete: a customer's SAML signing certificate, an identity provider's published signing keys and the DNS record that proves domain ownership, each a way in if checked loosely.

No single law covers login. The layers:

For a B2B app the questionnaire usually bites before any law. The strictest layer you face sets your defaults, and enforcers of the vaguer layers use the specific ones as their yardstick: the UK's ICO and the US FTC have both cited missing MFA. Authorization has almost no law behind it.

Every reversal is also an attack path: resets, passkey removal, token revocation, unlinking accounts, disconnecting SSO, role changes, transferring an organization's ownership.

Recovery is the exception every MFA rule allows, which is why attackers target it. Money follows its own rules: in the US a consumer's liability for an unauthorized transfer depends on how fast they report it ($50, $500 or unlimited), while a payment someone was tricked into sending usually counts as "authorized". In the EU, if the payer's provider skipped strong authentication, the payer isn't liable unless they acted fraudulently.

Who pays after a takeover is settled in the contract, by the regulator, in court and by the insurer.

I read two vendors' terms directly. Okta's master subscription agreement caps liability at the fees paid in the 12 months before the incident, excludes lost data and consequential damages, has no separate cap for security incidents, and makes the customer responsible for activity under its users' logins. Clerk's standard terms (updated October 1, 2026) have the same 12-month cap, cumulative across claims, with no data-breach carve-out. I didn't confirm other vendors' current terms, and negotiated contracts can differ.

"Whoever skipped MFA pays" is only the opening rule. The cap limits what can move to a vendor to a year of fees, against losses that can run to millions. Insurance pays only if your MFA answers were true (in 2022 an insurer had a policy rescinded after the customer overstated its MFA), and 23andMe's class settlement came from insurance and then a bankruptcy estate.