AADSTS65001 Error: Dynamics 365 OData access issue after 60min / token refresh

Question

My web app (ConfidentialClientAplication) performs some background tasks for my users:

1. Poll E-Mail inbox for new mails and import them - using the Microsoft Graph API (using Mail.ReadWrite)
2. Poll Dynamics 365 Finance and Operations data for new/deleted/changed data - using the OData endpoints, for example $DYN365_BASE_URL/data/Companies (using Connector.FullAccess)

For reference here is a screenshot of the permissions the app is using:

(Figure 1: App registration permissions)

--

In my webb app the user clicks a button to connect their MS365 tenant with my app, requesting the required permissions using the authorization code flow:

(Figure 2: Consent Screen)

I now have an access_token and also a refresh_token (using MSAL for Java). I can now successfully:

• Read the E-Mails
• Read the Dynamics 365 OData

So far, so good.

--

Now, after 60minutes my access_token is expired and I need to get a new one using the refresh_token. So, I do that.

Using the new access_token I can

• Still successfully read the E-Mails
• However trying to read the Dynamics 365 OData, I get an Exception: AADSTS65001: The user or administrator has not consented to use the application.

--

• Why?
• What I can change, to maintain access to the Dynamics 365 OData after 60min?

Answer 1

We found a rather simple solution: we needed to also add the Odata.FullAccess permission in the Azure portal.

Using the following set of permissions the code worked fine without any further modifications:

We also experimented with using less permissions. But it looks like all of the permissions are required for our use case.

Answer 2

First of all you seem to have mixed up OAuth flow here. Confidential client is for app only permissions like Mail.ReadWrite which you have there.

Since I see use consent on the screenshot, this means users interact with your app and consent to the delegated permissions. If you are receiving a refresh token, there should be offline_access scope.

From the screenshot, Mail.ReadWrite is an app only permission which means that if you request a token you don't need user interaction.

My suggestion:

Review and add only permission types that make sense to your app. Ideal situation is an an is either confidential client (application permissions) or public client (delegated permissions). That way when requesting tokens after user interaction (all permissions delegated) you get a refresh token that will give you an access token with the exact same permissions.

If this is not the solution, then share the scopes passed in the authentication experience as well as token passed in token renewal request.