Authentication in Dynamicweb

Generally, there are two ways of working with authentications in Dynamicweb:

• Authentications in Endpoint management
• Client credentials in Dynamicweb Connector Service

Endpoint authentications are managed in Settings > Integration > Endpoint Management.

They can be of any supported type and can be tied to one or more endpoints with the Endpoint authentication dropdown.  

Figure 2.1 Add authentication screen in Dynamicweb

The suitable type of authentication for you integration project depends on the remote system you wish to integrate with and whether it is cloud-hosted or local.

An integration with a cloud hosted ERP system will most likely require authorization through the OAuth 2.0 protocol. Communicating with local hosted solutions on the other hand, can most likely make do with a simpler method of authentication such as Basic, ntlm or WSAK.

There are two distinct ways of working with OAuth 2.0. The recommended way is to use Service-to-Service authorization (S2S), where your Dynamicweb solution is authorized access directly to the remote system.

An S2S authentication between DynamicWeb and a remote system allows you to configure required permission on an application level as opposed to a User impersonation authentication, where the permissions reflect the permissions of a given user. The differences between S2S and user impersonation OAuth is outlined further in this Microsoft learn article.

Service-to-service OAuth takes a ClientID, a TenantID and a client secret of an Azure Active Directory app registration and exchanges access tokens in the background and independently of user credentials. Check out our comprehensive S2S guide to learn more about adding such an authentication for Dynamics 365 Business Central, CRM or F&O.

Just like an S2S OAuth, a User impersonation setup requires a TenantID, a Client ID and a ClientSecret from Azure Active Directory, but in addition to these, an access token is required to authorize access to the remote system. Access tokens are obtained via the credentials of a user in the remote system and the authorization will mirror the permissions tied to that exact user. Which data can be accessed and modified through the authentication will thus depend on the credentials configured for the impersonated user.

You can read more about how to establish OAuth for the systems currently supported in Dynamicweb here:

• OAuth User impersonation for Business Central
• OAuth User impersonation for Dynamics CRM
• OAuth User impersonation for Finance & Operations

Endpoints exposed from an on-prem solution via the Dynamicweb connector service or the Dynamicweb Connector TestTool can be accessed with authentications such as these:

• Basic: Authentication with a username and a password
• WebServiceAccessKey: Business Central can assign web access keys to users. These keys can be valid from one date and be invalid after a certain date. These keys are auto-generated and is used instead of a password. WebServiceAccessKeys can be used for on premise solutions as well as cloud-hosted test enviroments. 
• Ntlm: NTLM is an authentication protocol used in windows networks. It allows you to provide a domain and windows user to access endpoints within the same network as the Dynamics ERP system. This is useful in development and on premise scenarios.

Figure 7.1 Adding an authentication in Dynamicweb endpoint management

The Dynamicweb Connector Service is a tool which functions as the bridge between the Dynamicweb solution and the ERP system. It is typically installed on the DMZ/Perimeter network of your environment, and handles data encryption and decryption. It can also function as an extensibility point when developing custom integrations.

The connector is supplemented by the Dynamicweb Connector TestTool, which is used to test connectivity between the components of an integration and to test requests/responses from remote systems.