Office365 AuthType Deprecation — An Alternative | Bitesize Series

Microsoft recently announced the Office365 AuthType deprecation used in connection strings, with many existing alternatives for authentication. This AuthType can be used to connect to Dynamics Online deployments through the SDK. It was indeed very convenient to use and saved some headache in properly setting up an Online deployment. Official retirement of Office365 AuthType is next year in April (2021).

It doesn’t take much effort, and it’s safer, to use the approach recommended by Microsoft. I know of three alternative ways to connect to an Online organisation: OAuth, Certificate, and Client Secret. I will discuss OAuth and Client Secret methods in this article.

OAuth

OAuth type can be used when building an app with direct user interaction. The user has to have an Office account, as there will be a popup requesting a username and password from the user.

Connection String

It can also be used for API/unattended access. The connection string template is as follows:

AuthType=OAuth; Username={username}; Password={password}; Url=https://{org}.{region}.dynamics.com/; AppId={appId}; RedirectUri=app://{appId}; LoginPrompt=Never

The connection string is pretty simple and straightforward. Let me show you how to acquire the AppId, and how to properly configure your tenant for access.

AppId

Login on to Azure portal, and search for Azure Active Directory.

Click on App Registrations.

Select New Registration.

Enter a name for your app, and then click Register.

The Application ID is highlighted below. Use it to replace the appId placeholder in the connection strings.

API Permissions

Select API Permissions from the side menu, and then add a new Permission.

Click on Dynamics 365.

Choose user_impersonation Permission, and then click Add.

Click Grant Admin Consent.

Public Access

Allow App Permission to be public: select Authentication, choose Yes under Default Client Type, and then click Save at the top of the page.

ClientSecret

For our purpose, ClientSecret is the appropriate replacement for the Office365 AuthType. The connection string template is as follows:

AuthType=ClientSecret; url=https://{org}.{region}.dynamics.com; ClientId={appId}; ClientSecret={clientSecret}

The connection string is simple as well. Let me show you how to acquire the ClientSecret, and how to properly configure your organisation to control privileges for this connection.

In this string, ClientId is equivalent to AppId in the previous type (OAuth).

Azure Configuration

Proceed to create the same App Registration as in the OAuth section above, following the steps in the AppId and API Permissions sections only.

ClientSecret

Select Certificates & Secrets, and then click on New Client Secret.

Choose your preferred expiry period.

Copy the Client Secret string, and replace the clientSecret placeholder in the connection strings.

Organisation Configuration

Open the target CRM organisation, and navigate to the Security -> Users section. Select the Application Users view, and create a new User.

Paste the Application ID with the value retrieved from Azure in the above sections; the rest of the data is redundant.

Assign a security role to the new User, just like any other user in CRM.

I personally prefer the Client Secret method; as I find it more practical, easy to set up as a service account, and secure.

It was just a matter of time before Microsoft forced Office365 AuthType deprecation, considering that the alternative methods are used in many web applications; I have to say that this was an inevitable shift.

The post Office365 AuthType Deprecation — An Alternative | Bitesize Series appeared first on Yagasoft.