Extend access token lifetime

Imagine you have an external system pushing some customer data to your Dynamics 365 environment overnight and sometimes it requires longer than an hour throwing a 401 error. In this article, I’ll describe how you can extend the lifetime of the access token used to connect to the Microsoft Dataverse API in order to resolve this issue easily.

In this example, I use the OAuth 2.0 client credentials flow, where we have created an application user in our Microsoft Dataverse environment.

Application users are connected to an Azure application that has been previously registered and it provides us with the corresponding client credentias (e.g. client ID and secret)

You can learn how to create a new application user in this article.

Using Postman, we can test our application user simulating the integration I mentioned at the beginning of the article.


Notice the default access token lifetime value of 3599 seconds (~1 hour) indicated by the attribute “expires_in“, which is acquired from the authentication request sent to the Microsoft identity service (login.microsoftonline.com).

In order to extend this value, we will create a new Azure policy and we will associate the same to the first-party app Common Data Service (CDS).

Azure first-party apps are the ones created and owned by Microsoft and you cannot delete them or change them. However, we can add a policy (at least for now 🤫) and modify its behavior to extend their authentication lifetime access token.

You can find the CDS first-party app ID and object ID in your azure portal linked to the same tenant where you have your Microsoft Dataverse environment:

IMPORTANT: The Common Data Service (CDS) first-party app represents all the Microsoft Dataverse environments in the same tenant, so that the lifetime token will be extended for ALL your application users in ALL your Dataverse environments under the tenant where we are applying this new policy.

In order to create the new policy, we are going to run the following Powershell commands:

>Install-Module -Name AzureADPreview

>Connect-AzureAD -Confirm

>$policy = New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"05:00:00"}}') -DisplayName "Custom CDS Policy" -IsOrganizationDefault $false -Type "TokenLifetimePolicy"

>Add-AzureADServicePrincipalPolicy -Id 0a474a94-9f53-4293-9278-225eea7733db -RefObjectId $policy.Id

Please notice 0a474a94-9f53-4293-9278-225eea7733db is my CDS app object ID and it is unique for each tenant, so that yours will be different, you just need to replace it accordingly.

Once you have run those commands, try again the same Postman request. In our example, we have increased the access token lifetime to 5 hours (5 hours ~= 17999 seconds):

I notice the policy may take ~10 seconds to be fully applied, so send your requests a few times until you see the new lifetime value.

Alternative solution: renew token

Although the solution described in this article may work initially and it may save you from changing some code, it is still not the most escalable solution 😢. What if the integration process connecting to the Microsoft Dataverse API run suddenly for longer that 5 hours? What if Microsoft suddenly decided to enforce a different policy?

The most resilient approach is basically to check when the token is going to expire and renew it before then, which requires some extra code in the the client application. If you are using .NET, this example may be useful.


You may find useful this Microsoft article, which describes the same commands I have used to apply this change as well as other additional details:

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s