Overview
Microsoft is deprecating several legacy authentication methods for SharePoint Online. Organisations that integrate SharePoint with reporting, data warehouses or line‑of‑business systems must move to modern authentication to avoid disruptions. This article explains which methods are being retired, defines the modern alternatives, and gives practical guidance for migrating service integrations such as AxioWorks SQList.
Key terms
Authentication: the process used to prove an identity to a service. In this context it is how a client (user or application) proves who it is to SharePoint Online.
Legacy authentication: older sign‑in methods that typically rely on username/password or interactive browser flows that are no longer recommended for unattended services.
Modern authentication: methods that use Azure Active Directory (Azure AD) tokens, certificates or delegated OAuth flows that are more secure and support modern security controls such as conditional access and multifactor authentication (MFA).
Legacy methods being deprecated
The most common legacy methods affected are:
- SharePoint Online Credentials — direct use of network credentials (username and password). Access is limited to the sites available to the user account used for the connection.
- Web Login — an interactive browser‑based sign‑in that supports MFA but requires a user to complete an interactive login flow. Access is limited to the user’s sites.
- App Only (SharePoint‑registered app) — uses an AppId and AppSecret configured directly in SharePoint. This method provided non‑user, application‑level access, but is being replaced by Azure AD‑centric approaches.
These legacy mechanisms are being retired because they cannot meet modern security requirements (conditional access, certificate‑based authentication) and they often depend on long‑lived secrets or interactive flows that are unsuitable for unattended services.
Modern authentication options
Microsoft recommends using Azure AD to manage application and delegated permissions. Two common patterns are:
- Azure AD Application Permissions — the application authenticates using a Client ID and a certificate (often a self‑signed certificate). This is an app‑only model: the application receives a token with permissions granted at tenant level and can access all sites subject to the permissions consented in Azure AD. This pattern is suitable for non‑interactive, long‑running services.
- Azure AD Delegated Permissions — the application acts on behalf of a signed‑in user. A Client ID is used and the user completes an interactive sign‑in; the resulting token reflects the user’s permissions and typically has a limited lifetime (90 days for refresh in some scenarios). This is appropriate where the application must enforce user context and per‑user access control.
Practical implications and examples
Which modern method to choose depends on the integration pattern:
- Background synchronisation services (ETL tools, scheduled replication) that must run without a user present should use Azure AD Application Permissions with a certificate. These services need stable, long‑lived, non‑interactive credentials and often require tenant‑wide access to several sites.
- Interactive tools that must respect per‑user access controls and operate with the user’s identity should use Azure AD Delegated Permissions. Delegated flows are appropriate for browser or desktop applications where a user signs in regularly.
For example, SQList users who replicate SharePoint lists into SQL Server should prefer Azure AD Application Permissions because SQList typically runs as a background service and needs reliable, long‑running authentication. AxioWorks provides configuration guides for both approaches: how to configure SQList with Azure AD Application Permissions and how to configure SQList with Azure AD Delegated Permissions.
See the AxioWorks support guide for Azure AD Application Permissions here: Configure SQList to use Azure AD Application Permissions.
Migration checklist — a pragmatic plan
Follow these high‑level steps when migrating from legacy to modern authentication:
- Inventory integrations: list every tool, service and scheduled task that connects to SharePoint Online and note the current authentication method.
- Classify by pattern: identify which integrations are unattended services and which require user context.
- Choose the Azure AD model: application permissions for unattended services; delegated permissions for user‑interactive scenarios.
- Register the application in Azure AD: create an App Registration, record the Client ID, and configure either a certificate (recommended for app permissions) or redirect URIs for delegated flows.
- Grant and consent permissions: an administrator must grant the required SharePoint scopes to the app in Azure AD and provide tenant consent if app‑wide access is needed.
- Test with least privilege: start with minimal permissions required and expand only when necessary.
- Replace credentials in the service: update configuration to use the Client ID and certificate or delegated flow and validate connectivity, preferably in a test environment before production cutover.
- Monitor and rotate: track certificate expiry and schedule rotation processes to avoid service interruption.
When this approach is appropriate and who it is for
Use Azure AD Application Permissions when:
- You run automation or replication services that must operate continuously without user interaction.
- You need a consistent, tenant‑wide view of data for reporting, ETL or synchronisation.
Use Azure AD Delegated Permissions when:
- The operation must respect the individual user’s permissions.
- The application is interactive and a user will sign in regularly.
This guidance is intended for architects, administrators and engineers responsible for integrating SharePoint Online with SQL Server, reporting platforms or line‑of‑business systems. If your organisation uses SQList to create a reliable SQL Server representation of SharePoint lists, the application permissions model will usually be the most practical choice for production synchronisation.
Benefits of moving to modern authentication
- Improved security: supports certificates, conditional access and MFA policies enforced in Azure AD.
- Reduced operational friction: removes the need for service accounts with passwords that expire or require interactive updates.
- Better alignment with governance: centralised permission management in Azure AD makes auditing and compliance easier.
- Reliable automation: app‑only flows enable stable, unattended synchronisation and reporting workflows.
Further reading
For a wider perspective on extracting value from SharePoint data and when to bring lists into a SQL Server repository, read our practical guide on integrating SharePoint data with line‑of‑business systems: Integrating SharePoint data with line‑of‑business systems.
If you are evaluating approaches for exporting SharePoint data to SQL Server, our article about options and trade‑offs provides context that complements the authentication decisions described here: Exporting SharePoint data to SQL Server: options, trade‑offs and when to choose each approach.
To understand why SharePoint is not a reporting database and why a dedicated SQL store often makes sense, see: Why SharePoint is not a reporting database — and what to do instead.
For considerations specific to securing replication tools and deployment architecture, our article on SQList security is also relevant: Why SQList is a secure choice for SharePoint–SQL replication.
AxioWorks supports modern authentication in SQList; details and step‑by‑step configuration are available in the support articles linked above and at the SQList product page: SQList.
#sharepoint #azuread #authentication #sqlserver #dataintegration #security
