OData Authentication for On-Premises D365FO

Hi Folks, 

Integrating with D365FO via OData is a powerful way to enable external systems to interact with ERP data. While cloud-hosted environments use Azure Active Directory (AAD) for authentication, on-premises deployments require a different approach—primarily relying on Active Directory Federation Services (AD FS). This post walks through the essentials of authenticating OData requests in an on-prem D365FO setup.

OData in D365FO exposes data entities over RESTful endpoints, enabling CRUD operations. In on-prem environments, authentication is handled by AD FS, which issues security tokens based on user credentials. These tokens are then used to authorize access to the OData endpoints.

Below are key component for this entire process, 

1. AD FS Configuration

ü  AD FS must be properly configured and integrated with D365FO.

ü  The AOS (Application Object Server) uses AD FS metadata to validate tokens.

ü  Ensure the AD FS XML configuration file is accessible to AOS.

2. Client Application Setup

ü  External apps (e.g., Postman, .NET clients) must be registered in AD FS.

ü  You’ll need:

ü  Client ID (from AD FS or Azure App Registration)

ü  Resource URI (typically the D365FO base URL)

ü  Token Endpoint (AD FS OAuth2 endpoint)

3. Token Acquisition

ü  Use OAuth2 protocol to acquire a bearer token.

ü  The token request includes:

§  grant_type=password

§  client_id

§  username and password

§  resource (D365FO URL)

ü  AD FS returns a JWT token if credentials are valid.

4. Calling OData

ü  Include the token in the Authorization header:  Authorization: Bearer <access_token>

ü  Use standard OData URLs like:  https://<your-d365fo-url>/data/Customers 

Lets take an example to authentication via Postman;

1. Get Token

ü  POST to AD FS token endpoint: https://<adfs-url>/adfs/oauth2/token

ü  Body (x-www-form-urlencoded):

            client_id=<your-client-id>

username=<your-username>

password=<your-password>

grant_type=password

resource=https://<your-d365fo-url>

 

2. Use Token

ü  Add Authorization: Bearer<token> header to your OData request.

3. Test Endpoint

ü  GET:  https://<your-d365fo-url>/data/Customers

Please be aware; 

• Token Expiry: Tokens typically expire after 1 hour. Refresh or reacquire as needed.

• AD FS Clock Skew: Ensure time sync between AD FS and AOS servers.

• SSL Certificates: AD FS endpoints must be secured with valid SSL certs.

• User Permissions: The authenticated user must have access to the data entities.

-Harry Follow us on Facebook to keep in rhythm with us. https:fb.com/theaxapta

Working with Bicep – Part 2: Azure Function App Deployment

Hi Folks, 

In Part 1, we explored how to use Azure Bicep to deploy Logic Apps and integrate with Dynamics 365 for Finance and Operations (D365FO). Now, in Part 2, we’ll extend that architecture by deploying Azure Function Apps using Bicep—enabling custom logic, token handling, and deeper orchestration capabilities.

Just for a recap, lets understand why Azure function is so awesome, Azure Functions are serverless compute services ideal for lightweight processing, transformations, and integrations. When paired with Logic Apps, they offer:

• Custom logic execution (e.g., token parsing, data shaping)
• Event-driven triggers (e.g., D365FO business events)
• Scalable backend processing without managing infrastructure

In todays post lets take a real time scenario, To authenticate Logic Apps with D365FO, you often need to retrieve an OAuth token. Here’s how an Azure Function can help, below is sample code which can be called from Logic Apps to retrieve and inject the token dynamically.

  Here are some known issues and their possible fixes (atlest they worked for me ;) )

-Harry Follow us on Facebook to keep in rhythm with us. https:fb.com/theaxapta