Forum Discussion
SharePoint ACS Retirement – Guidance Needed for Migration to Azure AD / Graph or Better if Available
1. Will existing ACS‑based integrations stop working after April 2026?
Yes.
App‑Only authentication using Azure Access Control Services (ACS) will be fully retired. This includes integrations that were registered via:
- /layouts/15/appregnew.aspx
- /layouts/15/appinv.aspx
- AllowAppOnlyPolicy="true"
- Token endpoint: https://accounts.accesscontrol.windows.net/{tenant-id}/tokens/OAuth/2
After retirement:
- Existing ACS App‑Only integrations will stop working
- Access tokens can no longer be issued
- AppInv.aspx trust model becomes unusable
- Runtime calls to SharePoint REST API will fail with HTTP 401 Unauthorized
This affects both new and existing implementations.
2. Recommended Modern Approach
You do NOT need to migrate to Microsoft Graph API if your current integration already uses SharePoint REST endpoints.
Microsoft supports the following modern authentication pattern:
- Azure AD App Registration
- OAuth 2.0 Client Credentials Flow
- SharePoint REST API
This allows you to continue using existing endpoints such as:
https://<org>.sharepoint.com/sites/<site>/_api/web/...
A migration to Microsoft Graph is optional and only recommended if:
- Cross‑workload integration is required
- No SharePoint‑specific functionality is needed
- Graph API coverage is sufficient for the scenario
For document upload / download scenarios in Business Central, continuing with SharePoint REST is typically the most appropriate option.
3. Can existing SharePoint REST API endpoints still be used?
Yes.
After switching to Azure AD authentication, existing REST API calls such as:
- File Upload
- File Download
- Folder Access
- Metadata Handling
can continue to use the existing:
_api/web/...
endpoints without functional changes.
Only the authentication mechanism changes.
4. Restricting Access to a Single SharePoint Site
In the ACS model, permissions were often granted tenant‑wide, for example:
Scope = http://sharepoint/content/sitecollection/tenant
Right = FullControlWith Azure AD App‑Only authentication, access can be restricted using the Microsoft Graph application permission:
Sites.Selected
Benefits:
- The application has no SharePoint access by default
- Access can be granted to specific site collections only
- No tenant‑wide FullControl permission is required
After assigning the Sites.Selected permission to the Azure AD application and granting admin consent, site‑specific access must be assigned once using Microsoft Graph.
Reference:
https://learn.microsoft.com/graph/api/site-post-permissionsGrant application access to specific SharePoint sites
5. Token Generation Using Azure AD
Instead of requesting tokens from:
https://accounts.accesscontrol.windows.net
Business Central must now request tokens from:
https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
Using:
- Grant Type: client_credentials
- Client ID
- Client Secret
- Scope: https://<tenant>.sharepoint.com/.default
Important:
When calling SharePoint REST API endpoints, the token scope must be:
https://<tenant>.sharepoint.com/.default
Using Microsoft Graph scope instead will result in an “Invalid audience” error when calling SharePoint REST APIs.
6. Migration Summary
Current ACS Model Future Azure AD Model AppRegNew.aspx Azure AD App Registration AppInv.aspx Sites.Selected Permission ACS OAuth Azure AD OAuth 2.0 accounts.accesscontrol.windows.net login.microsoftonline.com Tenant FullControl Site‑Scoped Access SharePoint REST API SharePoint REST API 7. Official Microsoft Documentation
- https://learn.microsoft.com/sharepoint/dev/sp-add-ins/retirement-announcement-for-azure-acs Azure ACS Retirement Announcement
- https://learn.microsoft.com/sharepoint/dev/solution-guidance/security-apponly-azuread SharePoint App‑Only Authentication with Azure AD
- https://learn.microsoft.com/graph/permissions-reference#sitesselected Microsoft Graph Permission – Sites.Selected
- https://learn.microsoft.com/graph/api/site-post-permissions Grant Application Access to a SharePoint Site
Architectural Recommendation for Business Central
- Azure AD App Registration
- Sites.Selected Permission
- OAuth 2.0 Client Credentials Flow
- Continue using SharePoint REST API
This approach is fully supported and requires minimal change to existing AL‑based upload / download logic beyond the authentication layer.
Microsoft1. Will existing ACS‑based integrations stop working after April 2026?
Yes.
App‑Only authentication using Azure Access Control Services (ACS) will be fully retired. This includes integrations that were registered via:
- /layouts/15/appregnew.aspx
- /layouts/15/appinv.aspx
- AllowAppOnlyPolicy="true"
- Token endpoint: https://accounts.accesscontrol.windows.net/{tenant-id}/tokens/OAuth/2
After retirement:
- Existing ACS App‑Only integrations will stop working
- Access tokens can no longer be issued
- AppInv.aspx trust model becomes unusable
- Runtime calls to SharePoint REST API will fail with HTTP 401 Unauthorized
This affects both new and existing implementations.
2. Recommended Modern Approach
You do NOT need to migrate to Microsoft Graph API if your current integration already uses SharePoint REST endpoints.
Microsoft supports the following modern authentication pattern:
- Azure AD App Registration
- OAuth 2.0 Client Credentials Flow
- SharePoint REST API
This allows you to continue using existing endpoints such as:
https://<org>.sharepoint.com/sites/<site>/_api/web/...
A migration to Microsoft Graph is optional and only recommended if:
- Cross‑workload integration is required
- No SharePoint‑specific functionality is needed
- Graph API coverage is sufficient for the scenario
For document upload / download scenarios in Business Central, continuing with SharePoint REST is typically the most appropriate option.
3. Can existing SharePoint REST API endpoints still be used?
Yes.
After switching to Azure AD authentication, existing REST API calls such as:
- File Upload
- File Download
- Folder Access
- Metadata Handling
can continue to use the existing:
_api/web/...
endpoints without functional changes.
Only the authentication mechanism changes.
4. Restricting Access to a Single SharePoint Site
In the ACS model, permissions were often granted tenant‑wide, for example:
Scope = http://sharepoint/content/sitecollection/tenant
Right = FullControl
With Azure AD App‑Only authentication, access can be restricted using the Microsoft Graph application permission:
Sites.Selected
Benefits:
- The application has no SharePoint access by default
- Access can be granted to specific site collections only
- No tenant‑wide FullControl permission is required
After assigning the Sites.Selected permission to the Azure AD application and granting admin consent, site‑specific access must be assigned once using Microsoft Graph.
Reference:
https://learn.microsoft.com/graph/api/site-post-permissionsGrant application access to specific SharePoint sites
5. Token Generation Using Azure AD
Instead of requesting tokens from:
https://accounts.accesscontrol.windows.net
Business Central must now request tokens from:
https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
Using:
- Grant Type: client_credentials
- Client ID
- Client Secret
- Scope: https://<tenant>.sharepoint.com/.default
Important:
When calling SharePoint REST API endpoints, the token scope must be:
https://<tenant>.sharepoint.com/.default
Using Microsoft Graph scope instead will result in an “Invalid audience” error when calling SharePoint REST APIs.
6. Migration Summary
| Current ACS Model | Future Azure AD Model |
|---|---|
| AppRegNew.aspx | Azure AD App Registration |
| AppInv.aspx | Sites.Selected Permission |
| ACS OAuth | Azure AD OAuth 2.0 |
| accounts.accesscontrol.windows.net | login.microsoftonline.com |
| Tenant FullControl | Site‑Scoped Access |
| SharePoint REST API | SharePoint REST API |
7. Official Microsoft Documentation
- https://learn.microsoft.com/sharepoint/dev/sp-add-ins/retirement-announcement-for-azure-acs Azure ACS Retirement Announcement
- https://learn.microsoft.com/sharepoint/dev/solution-guidance/security-apponly-azuread SharePoint App‑Only Authentication with Azure AD
- https://learn.microsoft.com/graph/permissions-reference#sitesselected Microsoft Graph Permission – Sites.Selected
- https://learn.microsoft.com/graph/api/site-post-permissions Grant Application Access to a SharePoint Site
Architectural Recommendation for Business Central
- Azure AD App Registration
- Sites.Selected Permission
- OAuth 2.0 Client Credentials Flow
- Continue using SharePoint REST API
This approach is fully supported and requires minimal change to existing AL‑based upload / download logic beyond the authentication layer.
Currently we are using the delegated permission in the azure and because of which from postman it is not allowing us to grant access to SharePoint Online, we can not use application permission because of the security concerns user has .
pls provide the way forward because with granting access we will not be able to upload and download the file.
Also as if its not possible with the application permission then if possible can u pls provide the references that suggest that application permission is completely safe and what so ever.- Matthias_Glubrecht
Hello Aryan,
based on the configuration shown, your application is currently using Delegated Permissions (e.g. Sites.Selected – Delegated).
In this model, the application always calls SharePoint Online on behalf of a signed‑in user.This means that the effective permissions are the intersection of:
- The permissions granted to the application
- The permissions assigned to the signed‑in user in SharePoint Online
As a result, authentication may succeed, but file upload or download operations will fail if the user context does not have the required permissions on the target site. This behaviour is expected in Delegated Permission scenarios.
Delegated Permissions are intended for interactive user applications and are not designed for:
- service‑to‑service integrations
- backend automation
- daemon applications
- API‑to‑API communication
- Postman‑based integration testing
For these scenarios, Microsoft recommends using Application Permissions (App‑Only).
To address security concerns regarding Application Permissions:
Using the Sites.Selected permission as an Application Permission allows granting access to explicitly approved SharePoint Site Collections only.
Without an additional site‑level assignment, the application initially has no access to SharePoint resources. [learn.microsoft.com]This follows the principle of least privilege and prevents tenant‑wide access.
In addition:
The Sites.Selected permission is available for both:
- Microsoft Graph API
- SharePoint Online REST API [laurakokkarinen.com]
depending on which API is used by the integration.
For reference, please see the official Microsoft documentation:
- Overview of Selected permissions in OneDrive and SharePoint [learn.microsoft.com]
- Working with SharePoint sites in Microsoft Graph [learn.microsoft.com]
Recommended approach:
- Configure the Azure App Registration with
Application Permission: Sites.Selected - Use certificate‑based authentication
- Explicitly grant the application access to required SharePoint Sites only
This enables secure upload and download operations without relying on user context.
Hi,
Thank you for the detailed explanation. I appreciate the clarity on the permission models.
I wanted to share what we have currently implemented and also raise a constraint from our customer's side that affects the recommended approach.
OUR CURRENT IMPLEMENTATION — DELEGATED WITH STORED REFRESH TOKEN
You are correct that we are using Delegated Permissions (Sites.Selected — Delegated). However, our implementation does not rely on an interactive signed-in user for every operation. Here is how it works:
1. Initial Setup (One Time — Admin Only)
A SharePoint Administrator logs in once via an OAuth 2.0 Authorization Code popup in Postman. This generates both an Access Token (valid 1 hour) and a Refresh Token (valid ~90 days).
2. Token Storage
The Refresh Token is securely stored in the Business Central DMS Setup table. This is a system-level store, not tied to any end user.
3. Daily Operations (Fully Automated — No User Interaction)
Every time a user uploads or downloads a file in Business Central, the system silently calls the token endpoint using the stored Refresh Token to get a new Access Token. The new Refresh Token returned is immediately stored back, replacing the old one (token rotation).
4. Automatic Renewal
A monthly Job Queue entry in Business Central automatically refreshes the token before expiry, ensuring the system is self-maintaining under normal conditions.
5. Permission Scope
We have used Sites.Selected (Delegated) combined with a one-time Microsoft Graph API call (POST /sites/{id}/permissions) to grant write access to one specific SharePoint site only. The app has zero access to any other site in the tenant.
In effect, this behaves similarly to a service account pattern — the signed-in user context is only involved once during initial setup by the admin, and all subsequent operations run silently using the stored token.
PERMISSION GRANT PROCESS
For the one-time site access grant, we temporarily added Sites.FullControl.All (Delegated) to the app, ran the Graph API permission grant call, and then immediately removed Sites.FullControl.All (Sharepoint - Delegated ) from the app registration. The app now permanently holds only:
- SharePoint — Sites.Selected (Delegated) — Permanent
- Microsoft Graph — User.Read (Delegated) — Permanent
This ensures the principle of least privilege is maintained after setup.
CUSTOMER CONSTRAINT — APPLICATION PERMISSIONS NOT PERMITTED
We understand and agree that Application Permissions (App-Only) with Sites.Selected is the Microsoft-recommended approach for service-to-service integrations, and we fully acknowledge the points raised in your message.
However, our customer's IT Security team has confirmed they will not approve Application Permissions on the Azure App Registration under any circumstances — including SharePoint — Sites.Fullcontrol.All (Delegated) temporarily for even 5 minutes during setup. This is a hard security policy on their end that we are unable to override.
pls suggest if there is any other way forward or if not or not good enough what should be explain them so that they stick with this or even better application Also i have one question even with the Application permission they have to give the full access permission to MS graph to grant the SharePoint site Access Once then remove the permission.
thanks that's a big help .
