How to avoid trusting an email domain as account membership

Use an email domain to find a possible account or identity provider, never to grant account membership or permissions. Authenticate a stable person or service identity, then look up that identity's active membership in the selected account and check the action and resource. A verified email address says the provider checked control of an address at a point in time; it does not say the person is employed today, belongs to this SaaS customer or should see its data. The answer changes only if your organization deliberately offers automatic onboarding: even then, create a controlled, revocable membership under an explicit tenant policy, rather than treating a string suffix as live authorization. OpenID Connect says the email claim need not be unique and that email_verified concerns control at verification time; its stable sub claim serves a different purpose. See the OIDC Core claim definitions.

This is an account isolation decision, not a debate about whether email verification is useful. A domain can be a good routing hint while remaining a poor access key.

Illustrative case: a familiar address, the wrong account

Illustrative case, not a reported incident: Crestline SaaS has a customer account for acme.example. Its login callback currently derives tenant = email.split('@')[1] and creates an active member when the domain matches. Acme later sells a division. A former employee's address is reassigned, a contractor obtains an approved alias, and a new subsidiary uses the same mail domain but is contractually separate. Each person can pass the email provider's sign-in. None of those facts alone answers whether they should access the existing Crestline account.

Imagine the account contains repository findings. The unintended action is concrete: someone who can sign in with a matching address could read Acme's technical report without an approved membership. A source review can identify the direct domain-to-member grant path. It cannot prove a real person used it, and it must still inspect any later membership gate that might deny access.

The trusted mapping should look like this instead:

NIST's current federation guidance distinguishes a federated subject identifier from changeable identity attributes such as email. The OWASP Authorization Cheat Sheet calls for explicit, request-time permission checks. The table is an engineering decision model informed by those sources, not a claim that OIDC or NIST dictates a particular SaaS membership database.

Migrate existing members without preserving the shortcut

Removing domain-based creation is only half the repair. Existing memberships may already have been granted by that rule. Re-labeling all of them “explicit membership” preserves the same unapproved authority in a different table.

Continue Crestline's synthetic case with three legacy rows:

These are invented records, not customer findings. The example's migration policy chooses to restrict unresolved authority until approved. A real migration needs an accountable owner and a continuity plan, but convenience cannot supply the missing approval evidence.

The target lookup is explicit:

validated issuer + stable subject → local identity
selected canonical account + local identity → membership
active membership + action + resource owner → authorization

The domain can still route Ana to Acme's configured IdP. It cannot decide which membership row she receives. Two valid subjects with the same email remain distinct unless an authorized linking process establishes their relationship. OIDC Core defines the stable issuer/subject pair and warns that email is not a unique identifier.

Prevent the next sign-in from undoing removal

Suppose Jo once had Acme access, was removed, and later signs in with the same corporate alias. A simplistic JIT handler sees no active membership and creates one. That turns removal into a temporary inconvenience.

A safer illustrative policy distinguishes states:

no membership history + approved current JIT policy → evaluate new provisioning
active membership → use current approved grants
removed membership → deny reactivation unless separately approved
pending/ambiguous identity → no protected account access

The removed state must survive whatever cleanup your design performs, or the provisioning authority must otherwise retain enough information to enforce the removal. This is a lifecycle requirement, not a demand for indefinite personal-data retention. Design the record and retention policy with the responsible owners.

JIT itself can be legitimate. For example, a customer may authorize a known IdP group to create a low-privilege pending or active membership under a documented policy. The security condition is that the configured connection, group mapping, eligibility and removal behavior are explicit. A domain suffix alone supplies none of those facts.

Verify the migration's negative cases

A useful synthetic acceptance set includes Ana's permitted login, Jo's denial for Acme while the subsidiary remains available, Lee's unresolved identity hold, and a removed member's failed JIT re-entry. Inspect the first protected response, not only the login page. A session created successfully may still need to be restricted until membership is established.

If the authoritative membership store is unavailable, do not fall back to the old domain rule. If multiple accounts share a domain, require a deliberate account selection or known invitation context before private account access. The completed design keeps domain routing useful while making authority visible, reviewable and revocable.

The decision record for Crestline

Old rule: matching @acme.example creates an active Acme member. Risk: domain control becomes authorization and may survive employee moves, aliases or mail reassignment. Replacement: domain routes to Acme's configured IdP; validated issuer + stable subject identifies the human; only current Acme membership and capability authorize a report read. Open question: whether an existing downstream gate already rejects unmatched subjects. Owner: identity service engineer. Acceptance evidence: same-domain nonmember denied; active member allowed only for owned resources; removed member denied on an old session; migration of existing users reconciled without email-only privilege transfer.

If the IdP cannot supply a reliable persistent identifier, suspend automatic linking and resolve identities through an approved process. OIDC pairwise subjects can differ across clients even for the same human. Preserve the configured issuer/subject binding and use an approved linking process when joining identities across clients; do not treat the different subject as permission to merge by email. Keep account discovery responses from disclosing private customer membership.

Keep account discovery useful without making it authoritative

Crestline can preserve a convenient sign-in experience after removing domain-based grants. A user may enter an email address to locate a configured sign-in method, choose an account they already know, or follow a valid invitation. The discovery step should produce a route into authentication or provisioning, not a session that already carries customer permissions.

For a shared domain, discovery may be ambiguous. Acme and its separately contracted subsidiary can both use acme.example while maintaining distinct memberships. Ask the user to choose the intended account through a suitable product flow, then validate access to that account after authentication. Do not resolve the ambiguity by unioning both accounts' roles or choosing the account with the broadest matching grant.

The response should also respect the product's account-discovery policy. It may be inappropriate to reveal every private customer account associated with an address or domain. A generic route to the configured identity flow can be useful without listing confidential memberships. The exact user experience is a product decision; the essential boundary is that discovery information never becomes an access decision.

Handle an email change as an attribute change

Suppose Ana's identity keeps the same validated issuer and subject but her address changes after a company rename. The membership lookup should follow the established identity binding, with contact details updated through the application's verified process. Requiring a fresh domain match for every request can incorrectly remove legitimate access; automatically assigning the new domain's account can grant illegitimate access. Neither follows from the email change itself.

Now consider the opposite event: the same email address appears under a different subject after a mailbox is reassigned. That is not evidence that the new identity owns Ana's old administrator membership. The migration table's Lee case illustrates this uncertainty. An authorized identity-linking process needs evidence beyond matching contact strings before transferring a privileged relationship.

Preserve the distinction in administrative tooling. A screen that lets support edit a contact email should not silently rewrite the stable identity key or move account memberships. If linking identities is a supported operation, expose it as a separate action with its own evidence, authority, and audit record. That makes accidental privilege transfer easier to notice and review.

Plan the transition for people whose authority is unclear

A domain-based legacy system may lack the records needed to adjudicate every membership at once. Crestline should identify which grants are well supported, which need an account administrator's decision, and which identities are ambiguous. A staged migration can preserve approved access while restricting unresolved authority under the organization's chosen policy. The stage should not be a hidden continuation of the old automatic grant rule.

Give customer administrators a reviewable list of their own memberships and roles, with enough identity context to make a decision. Keep other customers' accounts out of that list. Record who approved each retained privilege and how unresolved users can seek help. A continuity plan matters because a rushed lockout can pressure support into restoring access by the same email shortcut the migration was meant to remove.

After the transition, inspect both login and membership removal. A successful sign-in should not create an active membership unless the controlled provisioning policy permits it. A removed identity should not regain access solely because its address still matches the domain. The same negative case belongs in any later identity-provider migration, where new subjects and familiar email addresses can otherwise recreate the original ambiguity.

The useful outcome is not that email disappears from the product. It remains a contact attribute and sometimes a discovery or invitation input. The change is that current account authority has an explicit owner, a stable identity relationship, and a removal path that the next sign-in cannot silently undo.

Start by searching one login path for the exact point where a domain changes from hint to grant. Replace that operation with a membership lookup or controlled provisioning decision. Next, review invitation privilege escalation and account switching, where the same shortcut often reappears.