Office365 AuthType Deprecation – An Alternative | Bitesize Series

Ahmed Sawalhy   •   June 12, 2020

Microsoft recently announced the Office365 AuthType deprecation used in connection strings. This AuthType was the popular choice when connecting to Dynamics Online deployments through the SDK. It was indeed very convenient and saved some headache in properly setting up an Online deployment. Official retirement of Office365 AuthType is next year in April (2021). With many existing alternatives for authentication, there shouldn’t be an issue in making the transition to a supported method.

It doesn’t take much effort, and it’s safer, to use one of the approaches recommended by Microsoft. There are three alternatives to connect to an Online organization: OAuth, Certificate, and Client Secret. I will discuss OAuth and Client Secret methods in this article.

1. 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.

1.1 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}; 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.

1.2 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.

1.3 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.

1.4 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.

2. 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}; 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).

2.1 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.

2.2 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.

2.3 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.