A White Paper on Authentication Design Flaws and Better Practices for High-Volume Portal Users
Executive Summary
Insurance carriers increasingly operate as federations: several legally distinct companies, often one per state, share branding, infrastructure, and a common login system while keeping separate books of business and separate broker portals. For the broker or agency staff member who must pull commission statements from several of these portals in one sitting, this arrangement often fails in a specific and frustrating way. After a successful login to one member company, the browser holds a persistent credential that the shared login system treats as authoritative, and attempts to reach a second member company’s portal are refused, redirected back to the first company, or trapped in an error loop. The condition commonly lasts many hours, frequently close to a full day, regardless of whether the user logs out.
This paper identifies the programming decisions that produce this behavior, explains why they persist, and describes design techniques that would better serve users who must move between many related portals in a single working session.
1. The Problem in Practice
The typical sequence runs as follows:
- The user signs in to Portal A (member company for State 1), completes two-factor authentication, and selects “remember this device for 30 days.”
- The user downloads commission statements and logs out, or simply closes the tab.
- The user navigates to Portal B (member company for State 2) and enters credentials appropriate to that company.
- Portal B either rejects the login, silently signs the user in to Portal A again, displays an “unauthorized” or “access denied” message, or loops between redirects.
- The condition clears only after a long interval, commonly 8 to 24 hours, or after the user manually clears cookies, which also discards the 30-day device trust and forces 2FA again.
The symptoms point to a small set of well-understood design errors.
2. Root Causes
2.1 A Shared Identity Provider Session Scoped to the Wrong Boundary
Most federated carriers place a single identity provider (IdP), such as Okta, Microsoft Entra ID B2C, Ping Identity, ForgeRock, or a custom single sign-on (SSO) service, in front of all member portals. When a user authenticates, two distinct sessions are created:
- An application session with the individual portal (Portal A).
- An IdP session with the shared login service, stored in a cookie on the IdP’s domain.
Logging out of Portal A typically ends only the application session. The IdP session remains. When the user then visits Portal B, Portal B sends the browser to the IdP, the IdP sees a valid session, and it immediately returns the identity already established for Portal A, without showing a login screen. If that identity has no rights in Portal B, the result is an access error; if the IdP is configured to remember the “last tenant,” the user lands back in Portal A.
The duration of the problem usually matches the IdP’s configured maximum session lifetime. Values of 8, 12, or 24 hours are common defaults, which aligns closely with the “about a day” lockout broker staff report.
2.2 Tenant Context Stored in a Persistent Cookie
Many multi-tenant systems record which member company a user belongs to in a “tenant,” “brand,” “region,” or “company code” cookie. When this cookie is set on a shared parent domain (for example, .carriergroup.com rather than statea.carriergroup.com), it is sent to every member portal under that domain. If the cookie is given a long expiration date rather than being a session cookie, it survives browser restarts. Every subsequent visit to any member portal is then routed to the tenant recorded in the cookie, regardless of which portal the user actually requested.
This is a cookie-scoping error: the Domain attribute is too broad, and the Expires or Max-Age attribute is too long for information that should describe only the current working session.
2.3 Device-Trust Tokens Bound to Session State
The “remember this device for 30 days” option is meant to store one fact: this browser has previously passed 2FA for this user. A sound design stores that fact in its own cookie, independent of any login session. A weaker design bundles the device-trust token with the IdP session or the tenant cookie, so that the system treats “trusted device” and “logged in as this user in this company” as a single object. When that happens:
- The trusted-device record effectively pins the browser to one identity and one tenant.
- Clearing the session to escape the lockout also destroys the device trust.
- The user faces an unhappy choice between repeated 2FA and repeated lockouts.
2.4 Missing or Partial Single Logout
Standards such as SAML 2.0 and OpenID Connect define single logout (SLO) protocols that terminate the IdP session and notify all relying portals. Many implementations omit SLO or implement only “front-channel” logout that fails when a tab is closed or a redirect is blocked. The visible “Log out” button therefore ends the portal session while leaving the IdP session intact, which is the precise condition that blocks entry to a sibling portal.
2.5 No Account or Tenant Selection Step
Well-designed identity systems offer a parameter (in OpenID Connect, prompt=select_account or prompt=login) that forces the IdP to ask which account or tenant the user intends to use, even when a session exists. Federated carrier portals frequently never send this parameter, so the IdP silently reuses whatever identity it last saw.
2.6 Load Balancer and Server Affinity Cookies
A less common but real contributor is the “sticky session” cookie issued by a load balancer, which pins a browser to one back-end server. If member portals share infrastructure and that server is configured for one tenant, the affinity cookie can route requests for Portal B to a server that only knows Portal A. These cookies sometimes carry long lifetimes through misconfiguration.
3. Why These Flaws Persist
Several institutional factors keep these errors in place:
- Design for the typical user. Most portal users are brokers who work with one member company. Product teams test the single-tenant path, and the multi-tenant user appears as an edge case rarely represented in usability studies.
- Security incentives point one direction. Security reviews reward longer device trust and stronger 2FA, but rarely measure the cost of failed cross-tenant access. A lockout is logged as “user error” rather than as a design defect.
- Fragmented ownership. In a federation, the IdP may be operated by a shared services group while each member company owns its portal. Neither side owns the seam between them, which is exactly where the failure occurs.
- Vendor defaults. IdP products ship with conservative defaults (long sessions, silent SSO, no account picker), and federations often deploy them without tuning for multi-tenant broker use.
- Invisible cost. The labor lost by staff who wait hours, clear cookies, or repeat 2FA does not appear in the carrier’s metrics. It appears only on the agency’s payroll.
4. Better Programming Practices
4.1 Separate the Three Kinds of State
A sound design keeps three categories of browser state strictly apart:
| State | Purpose | Appropriate Lifetime | Appropriate Scope |
|---|---|---|---|
| Device trust | Skip 2FA on a known browser | 30–90 days | IdP domain only, keyed to user + device |
| IdP session | Avoid re-entering password | Short (30–60 minutes idle) | IdP domain only |
| Portal / tenant session | Current working context | Session cookie, cleared on logout | Exact host of each portal |
Under this model, logging out or switching tenants never disturbs device trust, and device trust never forces a particular tenant.
4.2 Scope Cookies Narrowly
Tenant and application cookies should be set as host-only cookies (no Domain attribute) or, better, with the __Host- prefix, which browsers enforce as secure, host-only, and path-root. This prevents a cookie set by statea.carriergroup.com from ever reaching stateb.carriergroup.com. Tenant context that must persist should be stored server-side and looked up from a session identifier, not carried in a long-lived client cookie.
4.3 Support Multiple Concurrent Sessions
Major consumer platforms have long supported several signed-in accounts in one browser, with an account switcher and per-account session indexing in the URL. Federated carriers can adopt the same pattern: the IdP maintains a list of authenticated identities and tenants, and each portal request specifies which one it intends to use. A broker with access to four member companies could then hold four valid sessions simultaneously.
4.4 Use a Single Identity with Multiple Tenant Entitlements
Where the same individual holds appointments with several member companies, the cleanest design gives that person one identity carrying entitlements for each company. Logging in once, with one 2FA challenge, would grant access to every portal the broker is appointed with, and a tenant selector on arrival would replace the current lockout. This approach reduces both friction and the security exposure created by multiple separate passwords.
4.5 Implement Real Single Logout
Logout should terminate the IdP session, notify all relying portals through back-channel (server-to-server) logout, and clear tenant cookies. Back-channel logout does not depend on the browser successfully following redirects, so it works even when a tab is closed.
4.6 Offer an Explicit “Switch Company” Path
A visible control that sends the user to the IdP with prompt=select_account or prompt=login, while preserving device trust, would resolve most reported lockouts without any deeper architectural change. This is among the least expensive fixes available.
4.7 Shorten Idle Lifetimes, Lengthen Device Trust
Security and convenience are better balanced by short idle session lifetimes combined with long device-trust periods than by long sessions combined with short device trust. The former lets a user switch contexts freely while still skipping repeated 2FA on a recognized machine.
4.8 Provide Machine-Readable Statement Delivery
For commission statements specifically, the deeper remedy is to remove the portal from the workflow. Secure file transfer (SFTP) drops, scheduled email delivery of statements, or a documented API with per-agency credentials allow agencies to retrieve statements from all member companies on a schedule. Industry data standards bodies such as ACORD already define commission and statement formats that federations could adopt.
5. Interim Mitigations for High-Volume Portal Users
Until carriers correct these designs, staff who must work across many related portals can reduce lockouts with browser-side isolation:
- Separate browser profiles. Chrome, Edge, and Firefox each support multiple profiles with fully independent cookie stores. Assigning one profile per member company means each profile keeps its own device trust and its own session, and they never collide. This is the most reliable workaround and preserves the 30-day 2FA skip in each profile.
- Firefox Multi-Account Containers. This extension isolates cookies per tab container within one window, achieving the same separation with less overhead.
- Targeted cookie deletion. Browser developer tools allow deletion of individual cookies for a single domain. Removing only the IdP session cookie and any tenant cookie, while leaving the device-trust cookie, can sometimes clear a lockout without forcing 2FA. Identifying which cookie is which requires some trial, but once known it becomes a repeatable step.
- Private windows as a last resort. A private window starts with no cookies and so bypasses the lockout, but it also carries no device trust, so 2FA will be required each time.
- Documenting the defect. A short written report to each carrier’s broker support or IT team, describing the cross-tenant lockout and noting its business cost, creates a record that the issue affects real workflows. Federations rarely fix problems no one has formally reported.
6. Conclusion
The persistent cross-carrier lockout is not a mysterious browser fault. It results from identifiable design choices: an identity provider session that outlives the portal logout, tenant information stored in long-lived cookies scoped to a shared domain, device trust entangled with session state, and the absence of an account-selection step. Each has a known remedy in current authentication standards. Federated carriers that separate device trust from session state, scope cookies narrowly, support multiple concurrent tenant sessions, and offer direct statement delivery would eliminate a recurring source of lost labor for the agencies that depend on them, at modest engineering cost and with no loss of security.
On the practical side, the separate-browser-profile approach in Section 5 is the one most likely to fix your situation by tomorrow: one profile per carrier, each with its own “remember me for 30 days,” and they should stop interfering with each other entirely.
