Repository navigation
B2B Identity Patterns Across Industries #2719
Replies: 7 comments 7 replies
Pattern 1: B2B SaaS — selling directly to businessesIndustries: collaboration tools (Slack, Notion, Zoom), CRM and sales platforms (HubSpot, Salesforce), project management (Asana, Linear), HR tech, finance tooling — most of modern SaaS. The relationshipA SaaS company sells a product directly to other companies. Each customer company gets its own workspace — its own employees, its own administrators, its own data. The vendor runs the platform. The customer runs themselves inside it. Who is involved
How identity shows upCustomers expect their employees to sign in with their own corporate identity, not a separate password just for the vendor's product. So a customer plugs in their own identity provider (Entra ID, Okta, Google Workspace) and from then on, their employees use the same credentials they already use everywhere else. Customers also expect their employees to see their own company's brand when they sign in — not the vendor's logo. The sign-in page, the recovery flow, the invitation emails should feel like an extension of the customer's own IT. The customer's admin manages the customer's people. They don't expect to call the vendor's support to add a new hire or reset a password. They also expect that whatever they're doing inside their tenant is invisible to other tenants — Walmart's admin should never have any view into Dell's data, even by accident. When the customer upgrades their subscription, the new features should just be available to their employees the next time they sign in. When they downgrade or churn, access should wind down cleanly. Why this is the baselineThis is the pattern most people picture when they hear "B2B SaaS." It's the simplest of the patterns covered here, and most of the others are variations or extensions of it. If we get this one right, much of the rest follows. |
|
Pattern 2: B2B Reseller — selling through partners who resellIndustries: cloud distribution (AWS, Azure, Google sold through regional resellers), Microsoft's CSP program for Microsoft 365, white-label POS and retail tech, white-label telecom products, MSPs reselling cybersecurity tools. The relationshipThe platform vendor doesn't sell directly to end businesses. They go through resellers — partner companies, often regional, who package and sell the product to their own customers. The reseller often white-labels the product under their own brand. The end customer might not even know who the original platform vendor is. This adds a third party in the middle: Platform → Reseller → End Customer. Who is involved
How identity shows upThe reseller needs real administrative authority. They're not just a sales channel, they're operationally responsible for their customers. They onboard new customers themselves without the platform vendor being in the loop. They set the branding their customers will see. They monitor their customers' usage and troubleshoot issues. But the reseller's authority stops at their own customer base. They can see their own customers; they can't see other resellers' customers. The platform vendor sees everything, because they're ultimately responsible for the platform. End customers expect the same things they expect in B2B SaaS. Their own brand layered on top of the reseller's, their own identity provider, their own admins. The fact that they bought the product through a reseller shouldn't materially change their day-to-day experience. Branding stacks: the platform's brand is hidden under the reseller's brand, and the end customer can optionally layer their own brand on top within whatever the reseller allows. When commercial relationships change — a reseller's agreement ends, a customer moves from one reseller to another — the platform vendor needs to handle the cascade without breaking access for end users any more than necessary. What makes this different from direct B2B SaaSThe third tier in the middle is a real party with real authority, not just a different kind of user. Their commercial relationship is with the end customer, not with the platform vendor's billing department. They're a partner to the platform vendor in a way that matters and the identity story has to reflect that. |
|
Pattern 3: B2B Partner — external organizations brought in for an engagementIndustries: construction (general contractors bringing in structural engineers, surveyors, legal firms for a project), professional services (consultancies on retainer with a client), accounting platforms where bureaus serve multiple client businesses, agency relationships in marketing and creative, defense and regulated industries with vetted external contractors. The relationshipAn organization brings in other organizations to do specific work. The external organizations are not customers buying the host's product. They're not employees. They're independent businesses that need access to a slice of the host's environment for the length of an engagement — a project, a contract, a retainer — and then they're done. There are two shapes worth calling out, because they look different at first glance but the identity problem is the same. Project-side partners. A construction firm running a bridge project brings in IronFrame Structural for engineering, ClearLaw for legal review, and Apex Surveyors for site work. Each of them needs access to the bridge project's drawings, documents, and workflows. None of them should see other projects the construction firm is running. When the project ends, their access ends. Service-side partners. An accounting SaaS platform has two kinds of customers: businesses that use it for their own bookkeeping, and accounting bureaus whose entire job is serving those businesses. A bureau's accountants need to log into the platform and operate inside their client businesses' workspaces — without being employees of those businesses. Same underlying need: one organization needs scoped, time-bound access into another organization's space. Who is involved
How identity shows upThe partner organization signs in with its own identity provider — they're an established business and they have one. They don't want to manage a separate password for every client engagement. When a partner employee signs in, they may have access to several client workspaces or several projects simultaneously. They pick which one they're working in, and the rest of the experience is scoped to that choice. An accountant might switch between five client books in an afternoon. The host decides what the partner can do; the partner decides who on their team does it. If IronFrame hires a new engineer mid-project, IronFrame's admin adds them and they get the same access the rest of IronFrame's team has on that project. The host doesn't get involved in that. Multiple partner organizations might be granted access to the same project or the same host. They share that space but they should not see each other's work. The legal firm and the engineering firm both touch the bridge project, but the legal firm doesn't see structural drawings and the engineering firm doesn't see contract negotiations. Engagements end. When the project closes or the contract expires, the partner's access goes away — without anyone having to remember to clean it up manually. If the same partner is engaged again later for a new project, the relationship can be re-established without starting from scratch. What makes this different from B2B SaaS and ResellerIn B2B SaaS, each customer is a self-contained island. In Reseller, the hierarchy runs strictly top-down. In Partner, two independent businesses are connected sideways — neither is the parent of the other, the relationship is bounded in scope and in time, and either side can walk away when the engagement ends. That lateral, time-bounded relationship is the defining feature of the pattern. |
|
Pattern 4: B2B Division — internal multi-tenancy inside one enterpriseIndustries: conglomerates with multiple operating subsidiaries, multi-brand retail groups, holding companies, government departments under a central ministry, large universities with semi-autonomous schools and faculties. The relationshipA single enterprise has multiple internal business units that operate semi-independently. Each division has its own brand, its own employees, often its own IT team, and sometimes its own regulatory regime. Despite that autonomy they all sit under the same parent organization, and the parent has both the right and the responsibility to govern them centrally. This isn't B2B in the commercial sense — the divisions aren't selling to each other. But from an identity perspective it has all the same separation concerns as B2B SaaS, with the extra wrinkle that there's a legitimate central authority that gets to set policy across all of them. Who is involved
How identity shows upEach division typically has an identity provider that predates the central rollout. Healthcare might be on Google Workspace, Finance on Entra ID, Logistics on Okta. Central IT does not want to consolidate these — each division's IT team should keep managing what they manage. So identity has to accommodate multiple identity providers under the same enterprise, with each provider scoped to its own division. Each division has its own brand and its own sign-in experience. A Finance employee should see Finance's brand, not the parent corporation's, and certainly not Logistics'. Central IT sets policy floors that no division can fall below. If MFA is required at the enterprise level, no division can disable MFA. But a division can be stricter than the enterprise default — Healthcare can require shorter sessions and passwordless-only authentication because of regulatory exposure, without forcing Logistics to do the same. Some applications and APIs are shared across divisions. Specific people in Finance and Logistics might both need access to a shared risk platform without merging the two divisions or exposing one division's user directory to the other. The enterprise restructures from time to time. Acquisitions happen, divisions split, units get folded into other units. The identity setup has to handle those transitions — federating an acquired company's existing identity infrastructure for a migration period, eventually merging users into the parent division, retiring the transitional structure. Central IT needs a single view across the whole enterprise — who's active where, who hasn't signed in for ninety days, who has elevated roles, where MFA compliance is slipping — with the authority to act when something needs correcting. What makes this different from B2B SaaSIn B2B SaaS, the tenants are independent companies that don't trust each other and shouldn't see each other. In Division, the tenants are units of the same legal entity — central IT has legitimate authority over all of them, audits cross all of them, and policy flows down from a parent that genuinely holds the parent role. The isolation between divisions is operational, not adversarial. |
|
Pattern 5: API Product B2B — selling APIs to other businessesIndustries: payments and fintech (Stripe, Adyen, Plaid), communications (Twilio, SendGrid), banking-as-a-service, data providers (financial data, location data), embedded infrastructure (search, identity, mapping). The relationshipThe product isn't a UI application that people sign into and use. It's a set of APIs that other companies integrate into their own products. A fintech startup builds their app on top of Stripe; their end customers never sign into Stripe directly. A logistics platform uses Twilio for SMS notifications; their drivers never know Twilio is involved. So the B2B customer here is a developer-led organization, and the "users" of the product are mostly the customer's own backend systems calling APIs. Who is involved
How identity shows upThe customer organization signs up, picks the API products they want (a customer might want Payments and Analytics but not Identity), and is billed accordingly. Their tier determines rate limits and pricing. Most of the day-to-day "identity" interaction is the customer's developers issuing machine credentials for their backend services to use. Those credentials are scoped to the products the customer has subscribed to — a leaked credential can't be used against APIs the customer never paid for. Every API call needs to be unambiguously attributable to a specific customer. The platform's billing, abuse detection, and rate limiting all hang off knowing which customer is making the call. Larger customers want to manage multiple environments and multiple internal services under their account without involving the platform vendor in every credential rotation. Overlap with other patternsAPI Product B2B rarely shows up in isolation. The same customer often consumes both a UI product and an API product from the same vendor — Stripe has a dashboard that humans use and APIs that machines use, and both run off the same customer account. So this pattern usually layers onto one of the others rather than standing alone. |
|
Pattern 6: IDaaS — selling identity itself as a productIndustries: Auth0, Frontegg, Kinde, WorkOS, Clerk — the identity-as-a-service category. The relationshipThe product is identity infrastructure. The customer is a company that wants to outsource their own identity stack — login, user management, SSO, MFA, the whole thing — instead of building it themselves. So they sign up for the IDaaS platform and get what amounts to a fully-functioning identity tenant of their own, which they then use to manage their own end users and their own organizations. This pattern is recursive. The IDaaS customer is itself an identity provider for someone else's product. Whatever B2B model that customer is running internally — direct SaaS, reseller, partner, division — they'll want to run inside their IDaaS tenant. Who is involved
How identity shows upThe customer of an IDaaS platform gets a tenant that looks and behaves like a full identity deployment scoped to them. They configure their own applications, their own user types, their own roles, their own branding, their own identity provider connections. When their end users sign in, the experience is branded entirely as the customer's product. The IDaaS vendor's name doesn't appear. There's a clean split between two layers of administration. Platform administrators at the IDaaS vendor manage the platform itself — provisioning new customers, handling billing, managing abuse. Tenant administrators at the customer manage their own identity setup and never touch platform-level concerns. The two roles don't blur into each other. Larger customers care about where their identity data lives. A European bank using an American IDaaS vendor expects their user data to stay in Europe. So regional and data-residency separation is part of the offering for enterprise customers, even though smaller customers may not need it. Relationship to the other patternsIDaaS is the meta-pattern. The IDaaS customer uses the platform to run any of the patterns above for their own end users. So the IDaaS model has to be expressive enough to host all of them. |
|
Shall we also include organization onboarding in the list of common patterns? In B2B scenarios, organization onboarding is a critical flow, similar to user sign-in and sign-up. Ideally, administrators should be able to configure and customize the onboarding journey for organizations as well, including steps such as KYC verification, approval workflows, domain ownership validation, compliance checks, subscription setup, and administrator invitation flows. This would allow organizations to tailor the onboarding experience to their business, security, and regulatory requirements in the same way they customize user authentication and registration flows. cc: @AnuradhaSK |
|
Thanks @pavinduLakshan for raising this. Organization onboarding is most relevant in the B2B SaaS and IDaaS patterns, where the onboarding journey is consumer-facing and self-serve. That said, I think org onboarding should be part of the self-registration flow rather than a separate concern. The registration flow can be extended to provision the organization and simultaneously provision the registering user within it — or grant them access to the provisioned organization. The key primitive here is a composable, orchestratable flow — the same way we think about authentication flows today, but applied to org onboarding. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Why this discussion
Before we go further with B2B in ThunderID, I want us to share a clear picture of how B2B identity actually plays out in different industries. The phrase "B2B" hides a lot.
A SaaS company selling to enterprises, a platform distributed through resellers, a construction firm pulling in external contractors, and a conglomerate governing internal divisions all describe themselves as "B2B". But the people involved, the trust between them, and the expectations they have of an identity system are very different. This discussion is an attempt to lay out those patterns side by side.
Themes that run across all the patterns
A few things show up in almost every pattern with small variations. Worth pulling out separately so we treat them consistently.
Sign-in routing. In every pattern, when a user lands on a login page, the platform has to figure out which organization's experience to show them. Sometimes that's the email domain, sometimes an explicit selector, sometimes a tenant-specific URL or subdomain, sometimes a remembered choice from a prior session. Different industries lean on different defaults, and customers within an industry often want to choose.
Branding. Every pattern has a branding layer, and they stack differently. In direct B2B SaaS it's vendor and customer. In Reseller it's vendor, reseller, and customer. In Partner the partner's user typically sees the host's branding because they're operating inside the host's environment. In Division it's the parent enterprise and the divisions underneath. In IDaaS the vendor disappears entirely and the customer's brand is what end users see.
Lifecycle and cascade. Organizations come and go. Resellers end agreements, customers churn, projects close, divisions merge, partner engagements expire. When something at a higher level ends, the right things at lower levels need to wind down cleanly — without manual cleanup, and without breaking things that shouldn't have been affected.
Delegated administration. Across every pattern, the same theme: the people responsible for an organization's identity setup should be able to manage it themselves without going up the chain. The platform vendor doesn't add employees to the customer's tenant. The customer's IT doesn't add engineers to a partner firm's team. The division IT doesn't ask central IT to reset a password. Where the line is drawn varies by pattern, but the principle is consistent.
Bring-your-own identity provider. In nearly every B2B pattern, the organization in question already has an identity setup and wants to use it. Forcing customers, resellers, partners, or divisions to manage a parallel set of credentials is a non-starter for enterprise adoption.
What I'd like input on
Pattern completeness. Are there B2B patterns from industries we haven't covered that don't fit cleanly into these six? Marketplace models, franchise structures, federated industry consortia, healthcare provider networks — would any of these need their own pattern, or do they fold into one of the ones already here?
Pattern boundaries. Where patterns overlap (B2B SaaS plus API Product, Division plus Partner, IDaaS hosting any of the others), is the line clean enough? Or are there real customer cases that sit genuinely between two patterns?
The Partner pattern. This is the one that feels structurally most different — lateral access between independent organizations rather than hierarchical containment. Does the framing here match what folks have actually seen in real customer scenarios?
Industry coverage. I've pulled examples from the industries I know best. If you've worked closely with verticals I haven't covered well (healthcare, government, education, telecom), do these patterns describe what you've seen, or are there industry-specific shapes I'm missing?
Priority. If we have to sequence the patterns rather than tackle all of them at once, which patterns should come first based on where we expect customer demand?
Looking forward to thoughts and pushback before we move into modeling.
All reactions