When you’re building SharePoint-based client portals or external collaboration sites on Microsoft 365, one of the earliest architecture decisions you’ll face is how to handle authentication for users outside your tenant. It sounds straightforward until you’re three conversations deep with a client’s IT team and realize their requirements don’t fit the pattern you assumed.
Law firms have been building SharePoint-based client extranets for years; secure spaces where clients can access matter documents, collaborate with attorneys, and exchange files without resorting to email. What has changed is the identity landscape. Clients arrive with their own IdPs, their own MFA requirements, and their own expectations about how they’ll log in. The decision about how to authenticate them is no longer just a technical configuration – it shapes your entire external collaboration architecture.
For law firms, the stakes are higher than in most industries. You’re not just managing access to a shared document library – you’re managing access to privileged, confidential matter information. A misconfigured SharePoint permission doesn’t just create an inconvenience; it can create an ethical conflict. The architecture you choose for external client SSO directly shapes how well you can enforce matter confidentiality, prevent cross-client data exposure, and meet your professional responsibility obligations.
Two architectures come up repeatedly in this space: Entra ID B2B with Cross-Tenant Access and Access Packages, and a dedicated external Azure tenant fronted by a third-party identity provider. Both can get external users authenticated and into a SharePoint site. But they serve different needs, carry different operational costs, and make different assumptions about your clients’ environments.
For law firms, the stakes are higher than in most industries. You’re not just managing access to a shared document library – you’re managing access to privileged, confidential matter information. A misconfigured SharePoint permission doesn’t just create an inconvenience; it can create an ethical conflict. The architecture you choose for external client SSO directly shapes how well you can enforce matter confidentiality, prevent cross-client data exposure, and meet your professional responsibility obligations. Two architectures come up repeatedly in this space: Entra ID B2B with Cross-Tenant Access and Access Packages, and a dedicated external Azure tenant fronted by a third-party identity provider. Both can get external users authenticated and into a SharePoint site. But they serve different needs, carry different operational costs, and make different assumptions about your clients’ environments.
This article focuses on the architectural reasoning behind each pattern – the tradeoffs that should drive your decision, not the implementation steps.
Understanding the Stack: SharePoint as a Collaboration Surface
Before evaluating SSO patterns, it is worth being precise about what role SharePoint actually plays in a law firm’s document architecture – because this shapes everything else.
In most law firms, SharePoint is not the system of record for matter documents. That role belongs to the Document Management System – iManage, NetDocuments, or a similar platform purpose-built for legal document governance. The DMS is where documents are filed, versioned, access-controlled, and retained. It is also where ethical walls are enforced.
SharePoint, in this context, serves as a collaboration surface. Attorneys use it to share selected documents with clients, exchange drafts, and collaborate on work product in a structured, secure space. A sync layer – a tool that selectively bridges the DMS and SharePoint – surfaces specific documents from the DMS into client-facing SharePoint collaboration spaces. Documents flow from the DMS into SharePoint for collaboration purposes; the DMS remains authoritative.
This architectural reality has a direct bearing on how you think about SSO and governance. The ethical wall enforcement that prevents one client from seeing another’s documents is primarily enforced at the DMS layer – not at SharePoint, and not at the identity layer. A client successfully authenticating into a SharePoint collaboration space does not give them access to documents that the DMS and sync layer have not explicitly made available to that space.
This does not diminish the importance of SSO architecture. It means you need to evaluate your SSO pattern in the context of this full stack — understanding which governance controls live at the identity layer, which live at the SharePoint layer, and which live at the DMS layer — rather than expecting any single layer to carry the full governance burden.
The Core Constraint: SharePoint Only Speaks Entra ID
With that context established, here is the platform constraint that drives the SSO architectural decision.
SharePoint Online has exactly one supported authentication provider: Entra ID. There is no native way to plug Okta, Ping Identity, Auth0, or any other third-party IdP directly into SharePoint. Every user who accesses a SharePoint site – internal or external – must be represented as an identity in an Entra ID tenant. Full stop.
This constraint is what makes external client authentication non-trivial. If your clients use non-Microsoft identity platforms, you cannot simply point SharePoint at their IdP and call it done. You have to architect around the limitation. The two patterns in this article are, at their core, two different answers to the same question: how do you get clients with diverse identity platforms into a SharePoint site when SharePoint only understands Entra ID?
Pattern 1 answers it by bringing external identities into your existing Entra ID tenant as B2B guests – Entra federates with the client’s IdP and issues a guest principal that SharePoint recognizes.
Pattern 2 answers it by standing up a dedicated Entra ID tenant for external use and placing a third-party IdP in front of it. The third-party IdP handles the identity brokering and authentication flexibility; Entra ID still does the SharePoint authentication on the back end. The client never needs to know or care that Entra is involved – they authenticate through whichever method their organization supports, and the IdP translates that into an Entra-compatible session.
Understanding this constraint also explains why you cannot simply choose your preferred IdP and wire it directly to SharePoint. The architecture decisions that follow are all shaped by working within – or around – this boundary.
The Two Patterns
Pattern 1: Entra ID B2B with Cross-Tenant Access and Access Packages
In this model, external users are invited into your internal Microsoft 365 production tenant as B2B guest accounts. With Cross-Tenant Access Settings, you can establish trust relationships with specific external tenants, controlling which of their users can authenticate and what claims you’ll accept from their IdP. Access Packages (part of Entra ID Governance) layer on top, giving you a structured way to bundle SharePoint site access, group memberships, and other resources into a requestable, time-limited entitlement.
Authentication flows through Entra ID. The external user signs in with their home tenant credentials, Entra ID federates the trust, and your tenant issues the session. From a SharePoint Online perspective, these users land as standard guest principals – fully supported by the modern SharePoint Online permission model.
This pattern works well when your clients are also Microsoft 365 shops with their own Entra ID tenants. The cross-tenant trust is clean, MFA claims can be honored across the boundary, and the overall experience for the end user is seamless.
Pattern 2: Dedicated External Tenant with a Third-Party IdP
In this model, a firm operates a second, separate Azure tenant – purpose-built for external client collaboration. This tenant has no trust relationship with the internal production tenant. Matter data, internal systems, and firm resources live in the production tenant; client-facing collaboration lives in the external tenant. The boundary between them is architectural, not policy-based.
A third-party identity provider – such as Okta, Ping Identity, Auth0, or others – sits in front of the external tenant. Clients authenticate through whichever method their organization supports: federated SSO from their own IdP, SAML2 assertions, OIDC, social identity, or direct credential management through the IdP itself. The third-party IdP handles the authentication flexibility that SharePoint cannot provide natively; Entra ID in the external tenant remains the authentication provider SharePoint requires, but the IdP abstracts that complexity away from the client entirely. You are not locked into requiring clients to have an Entra ID tenant. If a client uses any SAML2 or OIDC-capable IdP, it can federate directly. If they have no enterprise IdP at all, the third-party IdP can manage their credentials directly.
The core architectural decision here is the separation of tenants. Client users operate entirely within the external tenant and have no path – even accidentally – into the internal production environment.
When to Use Entra ID B2B (Pattern 1)
Your client is a Microsoft 365 shop – Cross-tenant B2B trust works cleanest when both sides are on Entra ID. The client’s users authenticate with credentials they already use every day, MFA is honored across the trust boundary, and there’s no separate identity lifecycle to manage on your end.
You need a rich, integrated collaboration experience – B2B guests in your tenant can access SharePoint Online with the full modern experience, participate in Teams channels, and interact with other Microsoft 365 services. If the use case demands more than basic document exchange – co-authoring, real-time collaboration, integrated workflows – B2B is better positioned to support it natively.
You want Access Package-driven entitlement management tied to matter lifecycle – Access Packages let you define exactly what a guest can access, set expiration dates, require periodic access reviews, and build approval workflows. For law firms, this maps naturally to matter lifecycle: provision access when an engagement opens, expire the package when the matter closes. Governance is built into the model rather than bolted on.
Client volume is manageable and engagements are well-defined – B2B works well when you can clearly scope each client’s access and actively govern guest lifecycle. The model becomes harder to manage as client volume grows and guest populations accumulate across many concurrent engagements.
When to Use the Dedicated Tenant with a Third-Party IdP (Pattern 2)
Your clients use diverse or non-Microsoft identity platforms – If a client uses Okta, Ping, a legacy SAML2 IdP, or no enterprise IdP at all, B2B cross-tenant trust is either unavailable or requires significant workarounds. A third-party IdP in a dedicated tenant accommodates the full range of client identity scenarios from a single integration point, regardless of what each client brings to the table.
You require data isolation at the infrastructure level, not just the policy level – In a B2B model, client isolation is enforced through permissions, Access Packages, and Conditional Access policies. Those controls are effective when configured correctly – but they are policy-based, which means a misconfiguration can create exposure. In a dedicated external tenant with no trust relationship to your production environment, the isolation is architectural. No policy error in the external tenant can expose your internal production data because there is no connection between them. For law firms handling highly sensitive matters, this distinction matters.
You need to support clients regardless of their technical maturity – Not every law firm client has a sophisticated IT organization. Some have no enterprise IdP. Some manage credentials in a basic directory with no federation capability. A third-party IdP can act as a full identity provider for clients who need it, or as a federation broker for clients who have their own. A single external tenant with a capable IdP in front gives you one consistent front door that accommodates the full spectrum of client technical environments.
You want to keep external identities entirely out of your production tenant – Some firms draw a deliberate architectural line: no external user accounts in the internal tenant, ever. A dedicated external tenant enforces this cleanly. Your production Entra ID stays firm-only – no guest objects, no cross-tenant trust entries, no external identity lifecycle to govern alongside your internal user population.
The Decision Framework
Before choosing a pattern, work through these questions:
1. What IdP does the client use?
If Entra ID, Pattern 1 is available and typically the simpler path. If the client uses a non-Microsoft IdP or no enterprise IdP at all, Pattern 2 handles the full range of scenarios more gracefully through a third-party IdP’s broader federation capabilities.
2. What is the sensitivity of the matter?
High-sensitivity matters – litigation, M&A, regulatory investigations – may warrant the stronger architectural isolation of Pattern 2. Routine client collaboration with lower confidentiality stakes may be well-served by Pattern 1 with well-governed Access Packages.
3. How many clients, and how long are the engagements?
Short-term, well-scoped engagements with a small number of client users favor Pattern 1. High-volume environments with many concurrent client engagements and long-running matters may benefit from the operational clarity of Pattern 2, where external identity lifecycle never touches your production tenant.
4. What collaboration experience is required?
Rich, integrated Microsoft 365 collaboration points toward Pattern 1. Document exchange and secure access with clients who need a reliable login experience regardless of their tech stack points toward Pattern 2.
5. Can you enforce cross-client isolation through policy, or do you need it at the infrastructure level?
This is the most consequential question for law firms. If your risk posture requires that no policy misconfiguration can ever create a cross-client data exposure in your production tenant, Pattern 2 provides that guarantee structurally. Pattern 1 can achieve strong isolation, but it requires disciplined, ongoing governance of every Access Package, Conditional Access policy, and guest permission assignment.
SSO Architecture Is One Layer of a Broader Governance Stack
The SSO pattern you choose is not, by itself, a complete governance solution. Authentication architecture determines how users get in. What they can see and do once they’re in is governed by a separate – and equally important – set of controls that span multiple systems.
This is particularly true in law firms, where the governance stack is deeper than the Microsoft 365 layer alone.
Ethical walls are primarily a DMS concern, not an identity concern – Most law firms enforce ethical walls at the Document Management System layer – not at SharePoint and not at the identity provider. DMS platforms purpose-built for legal use have their own ethical wall engines, often with dedicated third-party integrations designed specifically for legal conflict enforcement. These tools operate independently of your Microsoft 365 SSO architecture and are typically the authoritative enforcement point for matter confidentiality. When evaluating your SSO pattern, understand where your firm’s ethical wall enforcement actually lives and ensure your collaboration architecture is compatible with it – do not assume that Microsoft-layer controls replace or replicate what your DMS is doing.
The sync layer is a governance boundary – If your firm uses a sync tool to selectively surface DMS documents into SharePoint collaboration spaces, that sync layer is itself a governance control. Documents reach SharePoint only because they were explicitly published there. The access controls and ethical wall policies enforced at the DMS layer determine what ever reaches the SharePoint surface in the first place. Your SSO architecture governs who can access the SharePoint space; the DMS and sync layer govern what is in it.
Conditional Access policies – Beyond authentication, Conditional Access governs what conditions must be met for a session to proceed – device compliance, network location, MFA strength, session risk level. These policies apply to guest users as well as internal users and need to be explicitly scoped and tested for each external access pattern.
Data Loss Prevention (DLP) – DLP policies enforce rules about what data can be shared, downloaded, or transmitted – and by whom. For external client access scenarios, DLP is a complementary control that operates independently of your SSO pattern. A user who can authenticate is not necessarily a user who should be able to download or forward matter documents.
Access reviews and audit logging – Periodic access reviews ensure that entitlements remain appropriate as matters evolve and client relationships change. Audit logging provides the evidentiary record that access was governed correctly – important both for internal governance and for demonstrating compliance to clients or regulators.
Matter-level SharePoint permission governance – Regardless of SSO pattern, the permissions controlling which client users can access which SharePoint collaboration spaces must be provisioned consistently and reviewed regularly. This is where cross-client data exposure most commonly occurs at the Microsoft 365 layer; not at authentication, but at the resource permission layer.
The SSO architecture you choose shapes what Microsoft-layer governance tools are available to you and how easy they are to operate. But recognize that it is one layer in a governance stack that extends well beyond Microsoft 365. Plan it in the context of your full environment – DMS, sync layer, and identity – not in isolation.
Architecture Tradeoffs and Gotchas
Policy-based isolation requires sustained governance discipline – Pattern 1’s client isolation model is only as strong as the policies enforcing it. Access Packages, Conditional Access, and SharePoint permissions must all be consistently configured and regularly reviewed. In a law firm, this is not a set-it-and-forget-it operation – it is an ongoing governance commitment that needs clear ownership.
The 150-group cap in SAML token responses – Entra ID caps SAML token group claims at 150 groups. If a user is a member of more than 150 groups, Entra ID emits a groups overage claim instead of the full group list, and your application must query the Graph API to resolve group membership. In law firms where users may belong to many practice group, office, and matter-specific security groups, this limit surfaces more readily than in other industries. Design your group strategy with this ceiling in mind.
B2B guest lifecycle is an ongoing operational commitment, not a one-time task – Provisioning B2B guests is straightforward. Governing them over the lifespan of a client engagement – and cleaning them up when a matter closes or a contact departs – is the operational challenge. Without active lifecycle management, closed matters leave stale guest accounts in your production tenant. Access Packages with expiration dates and access reviews are the right tool, but they require a defined process and someone who owns it.
Third-party IdP federation requires coordination with the client’s IT team – Federating a client’s identity system with a third-party IdP involves configuring SAML2 or OIDC on both sides. This is not something you can configure unilaterally – it requires the client’s IT organization to participate, provide metadata, map claims, and test the integration. Budget time for this coordination, especially with clients who have less mature IT organizations or slower change management processes.
A dedicated external tenant doubles your operational surface area. Pattern 2 provides strong isolation, but operating two Azure tenants means two sets of Conditional Access policies, two audit log streams, two admin surfaces, and two environments to patch, monitor, and govern. The architectural benefit is real – so is the operational cost. Evaluate whether your team has the capacity to maintain both environments before committing to this model.
Cross-client data isolation is your responsibility at every layer – Neither SSO pattern automatically prevents one client’s users from accessing another client’s SharePoint collaboration spaces. That isolation is enforced through SharePoint permissions, security groups, and access entitlements – and those require deliberate, consistent provisioning for every engagement. And as noted above, your DMS ethical wall configuration is the upstream control that governs what documents are ever surfaced into those spaces. Both layers need to be right.
Conclusion
There is no universally correct answer between these two patterns. The right choice depends on your clients’ identity infrastructure, your firm’s risk posture, the sensitivity of the matters involved, and your team’s operational capacity.
What is clear is that the choice carries real professional responsibility implications. In a law firm, SSO architecture is not a purely technical decision – it is a governance decision. The pattern you choose determines how your firm controls access to client collaboration spaces, how well it integrates with your broader document governance infrastructure, and how confidently you can demonstrate to clients that their information is protected.
Pattern 1 – Entra ID B2B – is the right choice when your clients are on Microsoft 365, you need a rich integrated collaboration experience, and you have the governance discipline to manage guest lifecycle and Access Packages rigorously over the life of each engagement.
Pattern 2 – a dedicated external tenant with a third-party IdP – is the right choice when your clients use diverse identity platforms, when architectural data isolation is a firm requirement, and when you want external identities kept entirely out of your production tenant by design rather than by policy.
Large law firms may find themselves running both patterns simultaneously – B2B for enterprise clients already on Microsoft 365, and a dedicated external tenant for everyone else. If you go that route, invest in clear internal documentation that maps each client to their pattern, and ensure your governance controls cover both environments consistently.
Most importantly, evaluate your SSO architecture in the context of your full governance stack – not just the Microsoft 365 layer. Your DMS, your ethical wall infrastructure, your sync layer, and your identity architecture all need to work together. The firms that get external client collaboration right are the ones that treat it as a cross-system governance problem, not a single-platform configuration task.