Office365 AuthType Deprecation – An Alternative | Bitesize Series
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 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.
Is Public Access necessary? I thought it was not necessary for ClientSecret AuthType since the client secret is provided.
Hello, Walt.
As mentioned in the article at the beginning of the ‘ClientSecret’ section: ‘following the steps in the AppId and API Permissions sections only’; so, it’s not required indeed.
I was wondering if step 1.4 was really necessary.
It’s required for OAuth only — not ClientSecret.