In the next few months, Microsoft will be removing the legacy authentication protocol known as IDCRL (Identity Client Run Time Library) in SharePoint and force calls to rely on OpenID connect and OAuth Protocols. Since 2018, regular sign-in for services such as OneDrive and SharePoint has always relied on the more secure OpenID Connect and OAuth protocols; going forward we will enforce this for all authentical calls.
How to access telemetry to check whether your organization has made any IDCRL Calls
To access telemetry please log into the Microsoft Purview portal. Typically, users with following roles/permissions are allowed access to this portal.
- Global Administrator
- Compliance Administrator
- Purview Compliance Administrator
- Role Management Role (to manage role groups)
- Collection Admin, Data Curator, or Data Reader for governance tasks.
Go to https://compliance.microsoft.com or https://purview.microsoft.com depending on your organization’s configuration. Use your organizational account (not a personal Microsoft account).
Once logged in, please navigate to “Audit” on the left hand side panel. Then under “Activities – operations name” please select “IDCRLSuccessSignIn” as shown in screenshot 1. Select other filters as required and click on Search.
You will get telemetry output similar to screenshot 2 and 3 depending upon the information available.
How to mitigate IDCRL calls and move to modern Authentication
Definition of IDCRL Calls: There are 2 categories of calls referred to as IDCRL calls
- Category 1: Any use of the SharePointOnlineCredentials library within your codebase is an indication of IDCRL calls as
- This library leverages the IDCRL protocol under the hood for authentication with SharePoint Online. If your application or script is calling SharePointOnlineCredentials, it is using IDCRL authentication.
- Category 2: All calls to the following endpoints are using IDCRL protocol:
https://login.microsoftonline.com/rst2.srf (used to obtain the SAML BinarySecurityToken) https://TENANT.sharepoint.com/_vti_bin/idcrl.svc (used to exchange the BinarySecurityToken for the SPOIDCRL cookie)
Users should consider moving to modern auth protocols by using Microsoft Authentication Library (MSAL) for OAuth as this will ensure safe and secure continuity for both Category 1 and Category 2 calls mentioned above. MSAL provides methods to acquire security tokens that can be used to authenticate apps and scripts.
For comprehensive technical guidance on migrating to modern authentication, please consult this resource: Using modern authentication with CSOM for .NET Standard.
Additionally, your application must be registered in Microsoft Entra to acquire access tokens. For detailed steps on app registration, see: Configuring an application in Azure AD.
For more details and context on MSAL and OAuth, please visit the following links:
- What Is OAuth? | Microsoft Security
- Microsoft identity platform and OAuth 2.0 authorization code flow – Microsoft identity platform | Microsoft Learn.
- Overview of the Microsoft Authentication Library (MSAL) – Microsoft identity platform | Microsoft Learn
Alternative fix for category 1 calls (mentioned above): If your application or script leverages the “SharePointOnlineCredentials” library (from the Microsoft.SharePointOnline.CSOM NuGet package), an upcoming release of the package will give the option of transitioning from IDCRL to Modern Authentication protocol. Organizations can use the overloaded constructor SharePointOnlineCredentials(username, password, useModernAuth: true) to upgrade to OAuth. The upgraded NuGet package will be released soon & will be available from NuGet Gallery | Microsoft.SharePointOnline.CSOM
In some rare cases, calls are directly being made to GetAuthenticationCookie method to acquire cookies; This method is getting deprecated in the newer version of the NuGet package and would be replaced by AcquireTokenAsync method which will acquire OAuth token.
Additionally, if you have enabled Multi Factor Authentication in your tenant, then you need to pass a fourth parameter with SharePointOnlineCredentials constructor i.e (username, password, useModernAuth:true, interactiveAuth:true). The fourth parameter i.e “true” will allow for user intervention and enable interactive auth for the tenant.
In case admins don’t want user intervention then they can use App Only Authentication while registering their app on Entra as mentioned above.



0 comments
Be the first to start the discussion.