Dynamics 365 / CDS Authentication Considerations

This post discusses the following 2 options to authenticate to Dynamics 365 / CDS:

  • from a .NET framework application
  • from a non .NET framework application

1.) Authenticating from .NET Framework applications

When a .NET Framework application needs to be authenticated, the API Microsoft.Xrm.Tooling.Connector.CrmServiceClient() can be used. This is a straight forward method to authenticate and supports several authentication methods.

Authenticating to Dynamics 365 / CDS on-premises

Using CrmServiceClient(), one possible method of authentication is via AD & IFD. Please click on the click below for a detailed description.

C# application connecting to Dynamics CRM (on-premises)

Authenticating to Dynamics 365 / CDS online

Using CrmServiceClient(), authentication can be performed via OAuth, Certificate or Client Secret. Office365 is deprecated. For Azure AD to perform the authentication, Dynamics 365 needs to be registered as an app in AAD.



1.) When a plugin or custom workflow makes a call to Dynamics 365 / CDS (via the Microsoft.Xrm.Sdk.IOrganizationService Interface), it doesn’t need to authenticate since it’s running directly on Dynamics 365.

2.) When JavaScript (when it’s referenced within a Dynamics 365 form) makes a call to the Dynamics 365 Web API, the JavaScript doesn’t need to be authenticated. The reason being is that the call is using the logged in user’s authenticated details.

2.) Authenticating from ‘any’ application

When applications such as PHP, Python, JQuery, C# need to be authenticated, Azure Active Directory (AAD) can be used (where Dynamics 365 is registered as an app). The applications make use of the authenticaion library MSAL (or its predecessor ADAL) to connect to AAD.