Many organizations moving from on-premises SharePoint to SharePoint Online expect to reuse their existing SSO configuration – Okta, Ping, ADFS, or another SAML 2.0 identity provider.
Unfortunately, that approach no longer works in Microsoft 365.
Over the last few months, I’ve been working through this challenge while helping my team design modern authentication for client-facing sites. Here’s what we learned – and what you need to know before trying to connect your external identity provider to SharePoint Online.
How SSO Worked in SharePoint Server
In SharePoint Server (2013, 2016, 2019), we had complete control of authentication.
Administrators could configure trusted identity providers directly in Central Administration and use SAML 2.0 to connect any third-party IdP – Okta, Ping, ADFS, Shibboleth, you name it.
That flexibility made it possible to support external portals and extranets.
A typical flow looked like this:
- A user browsed to the SharePoint site.
- SharePoint redirected the user to the trusted identity provider.
- The IdP authenticated the user and issued a SAML token.
- SharePoint validated that token and granted access.
That model worked perfectly for on-premises environments, and it’s still supported today in SharePoint Server 2019.
Why SharePoint Online Is Different
When you move to SharePoint Online, you lose control of authentication at the application level.
In Microsoft 365, authentication is centralized under Microsoft Entra ID (formerly Azure Active Directory).
Every cloud service – SharePoint, OneDrive, Teams, Exchange, and others – relies on Entra ID for token issuance and validation.
You can’t modify that trust, add custom SAML endpoints, or bypass Microsoft’s security token service.
Microsoft put it bluntly in a support case we opened while investigating this issue:
“SharePoint Online (as part of Microsoft 365) only accepts authentication tokens that are issued via Microsoft Entra ID.
The *.sharepoint.com domains are reserved and cannot be used as custom endpoints for SAML configurations.”
(Microsoft Support Case T20251020.0140)
That statement tells you everything: direct SAML 2.0 federation with SharePoint Online is not supported – by design.
Why Direct SAML Federation Fails
SAML works by establishing a trust relationship between your application and an identity provider.
In SharePoint Server, we could configure that relationship directly.
In SharePoint Online, we can’t – because Microsoft owns and controls the trust for all *.sharepoint.com endpoints.
Even if you configure Okta or ADFS as a SAML provider in Entra, those tokens can’t be consumed directly by SharePoint.
They must first flow through Entra ID, which issues the final, Microsoft-managed token used by SharePoint Online.
In other words:
You can make Okta your Microsoft 365 login experience, but you can’t make it your SharePoint Online identity provider.
Supported Authentication Models
Here’s what does work today and what Microsoft supports:
| Option | Description | Typical Use Case |
|---|---|---|
| Entra ID Native SSO | Standard Microsoft 365 authentication using Entra credentials. | Internal users and corporate devices. |
| Entra B2B Guest Access | Invite external users into your tenant; they log in using their own organizational or Microsoft account. | External partners, clients, or vendors. |
| Cross-Tenant Synchronization | Automatically sync users from another organization’s Entra tenant into your own. | Partner organizations with cooperative IT teams. |
| Okta as Global IdP | Okta federated at the domain level for all Microsoft 365 authentication. | Enterprise-wide Okta deployments. |
| Okta/ADFS with SharePoint 2019 (On-Prem) | Traditional SAML 2.0 flow, fully under your control. | DMZ-hosted extranets and client portals. |
What This Means for Architects and Admins
If your solution depends on direct SAML federation, you’ll need to keep at least part of your SharePoint footprint on-premises.
SharePoint 2019 remains an excellent option for client portals, secure extranets, and environments requiring SAML 2.0 or Okta integration.
For cloud-hosted collaboration, Entra B2B guest access is the supported approach.
It’s clean, secure, and requires no custom federation configuration.
You invite users into your tenant, they use their existing business or Microsoft credentials, and access is controlled through groups and conditional access policies.
Lessons Learned
When Microsoft says, “Authentication must flow through Entra ID,” they mean it.
No amount of PowerShell tweaking or SAML XML editing will make SharePoint Online accept tokens from a third-party IdP directly.
It’s not a misconfiguration – it’s a platform restriction.
The key is to design your authentication strategy around where Microsoft is going, not where we came from.
That means embracing Entra B2B, cross-tenant collaboration, and guest user lifecycle management – instead of traditional SAML 2.0 federation.
Final Thoughts
If you’re still hosting SharePoint Server on-premises for external client access, that’s fine – in fact, it’s often the right choice for identity control and compliance.
But for Microsoft 365, the future is Entra-based collaboration.
The era of custom SAML federation for SharePoint is over.
The future belongs to Entra ID.
About The Author
