Microsoft retires ACS

Let me quote Microsoft just to start (Dec 18, 2023):

• “SharePoint App-Only is the older, but still very relevant, model of setting up app-principals.”
• “… we will be retiring the use of Azure ACS (Access Control Services) for SharePoint Online auth needs and believe Microsoft 365 customers will be better served by modern auth…”
• “Azure ACS will stop working for new tenants as of November 1st, 2024 and it will stop working for existing tenants and will be fully retired as of April 2nd, 2026…
  There will not be an option to extend using Azure ACS with SharePoint Online beyond April 2nd, 2026″
• “… we recommend switching those applications to use Microsoft Entra ID for authorization and authentication needs…”

So, for new development it is strictly recommended to use Azure Registered Apps to access Microsoft 365 resources programmatically.

You still need ACS in some cases

But, as always, it all is not so simple, as

• there are still plenty of 3-rd party applications written and used widely that require ACS-based permissions. Moreover, there are still some 1-st party applications (Microsoft apps and services) that require ACS-based permissions
• though Microsoft Graph API is good and provide a lot of functionality and is developing rapidly, it cannot cover all SharePoint dev’s needs, so using SharePoint REST API could be unavoidable… and that is where some complications are coming
• permissions to specific SharePoint sites (not to all tenant sites, but to one or several SharePoint sites in tenant) for apps is done via Sites.Selected, but this works to entire site collection only. E.g. via Sites.Selected you cannot provide granular permissions (e.g. to specific list) for an app, which might be crucial in some cases, so you’d still have to use ACS-based permissions

Hopefully, Microsoft will resolve all the issues above before April 2026… But for now we have to live with both – Azure Registered applications and API permissions configured in Entra ID and with SharePoint app-only service principals and ACS-based permissions.

Azure Apps and Entra Id vs SharePoint app-only spn and ACS

Comparison between Azure Apps and Entra Id API permissions vs SharePoint app-only spn and ACS-based permissions

ACS-based SharePoint app/permissions	Apps registered in Azure with Sites.Selected API permissions
support authentication with client secret only, secret is valid for 1 year exactly	support authentication with client secret and/or certificate, custom expiration time
support granular access to SharePoint site content – e.g. to entire site collection or web (subsite) or a specific list	support only access to entire site collection (but Microsoft is working on granular access) Now (Sep 2024) Microsoft supports granular (list, library, Item, Document level) access for an app to a site.
support only classic SharePoint REST API and CSOM	support both – classic SharePoint REST API and CSOM and Microsoft Graph API
app id (client id) is created via appregnew.aspx at a specific SharePoint site by site collection administrator	app id (client id) is created in Azure portal, API Sites.Selected permissions are configured via Azure portal and require tenant admin consent
permissions for the app to a site are provided at the site by site collection administrator via appinv.aspx page	permissions for the App to to a specific SharePoint site/list/item are provided by SharePoint admin with PowerShell script or Graph API calls
logging	audit log

SharePoint app-only service principal and ACS-based permissions

Since SharePoint app-only service principals and ACS-based permissions were introduced for SharePoint 2013 as part of Add-Ins feature – there are plenty of articles from Microsoft and MVPs and SharePoint gurus on this. But I would like to highlight one thing:

• AppRegNew page creates service principal and allows authentication
• AppInv page provides permissions and allows authorization to SharePoint

Check SharePoint AppRegNew.aspx and AppInv.aspx for details

Recommended transition tactics

For developers

• Prioritizing using Microsoft Graph API.
• In cases Graph API does not provide required functionality – it’s ok to use SharePoint API, but please ensure certificate is used (not secret).

For SharePoint admins

• Encourage users register applications in Azure (not in SharePoint)
• Disable ability for site owners register service principals in SharePoint via appregnew.aspx
  Your users will start seeing “Your SharePoint tenant admin doesn’t allow site collection admins…” message (see details), but that’s ok.
• Create a process so users can request application permissions to SharePoint. Provide Sites.Selected permissions by default. Consider automation.
  In rare cases when 3-rd party apps require legacy ACS-based permissions, it would be you (SharePoint service admin) who will provide ACS-based access to sites.
  Track this activity (so you know for whom this ACS-based permissions were provided).
  Inform every developer that ACS will be gone.
• Keep audit logs
  Starting today and until it’s over you’d get audit logs from Microsoft 365 purview center – consider selecting all events anyone visited appinv.aspx page.
• In March-April 2025 (1 year before) ACS EOL, start notifying developers who use ACS.
  You can get list of developers combining
  – audit log data
  – report from Entra Id on apps owners
• In advance ( let say, starting September 2025) you can try to temporary switch off ACS (“scream test”).

References

• Using AppRegNew (authenticate) and AppInv (authorize) for SharePoint app-only spns and ACS
• recent update to Microsoft 365 MC660075 that disables for site collection admins to create an Azure Access Control (ACS) principal via AppregNew
• Sites.Selected API permissions for SharePoint access
• Secret vs Certificate for Connecting to SharePoint Online programmatically
• SharePoint API vs MS Graph API