AADSTS65001 consent_required even though permission is already granted (FME 2026.3, Azure AD web service)

Hi ​@ecx! I have a few thoughts on where the error: invalid_grant and "suberror": "consent_required" messages could be coming from.

A new/altered app registration may require you or your Azure admin to grant consent again. You can find that option in the App registration under Manage > API Permissions, where you can confirm that Grant admin consent for [company] is selected and the API/Permissions Status all show checkmarks.

Another place to check is the Enterprise Application section, which controls tenant-level consent settings. That's under the Enterprise Application's Security > Permissions page.

The Client ID in the FME web service itself is still worth a quick check too. Old client details or stray characters can cause issues!

Hi ​@ecx! I have a few thoughts on where the error: invalid_grant and "suberror": "consent_required" messages could be coming from.

A new/altered app registration may require you or your Azure admin to grant consent again. You can find that option in the App registration under Manage > API Permissions, where you can confirm that Grant admin consent for [company] is selected and the API/Permissions Status all show checkmarks.

Another place to check is the Enterprise Application section, which controls tenant-level consent settings. That's under the Enterprise Application's Security > Permissions page.

The Client ID in the FME web service itself is still worth a quick check too. Old client details or stray characters can cause issues!

Hello, thank you for the reply.

I believe that the sys admin has already granted me consent, as he says he has, but I will get him to check again, using your instructions. 

Would you have any other suggestions if consent was already granted?

Hi again, I have checked with the sys admin and those have been granted using his global admin account.

Do you have any suggestions of what to try next?


Thanks,

Hi ​@ecx! I believe you may have run into a recent change to the underlying web service. In FME 2026.3, Microsoft Azure Active Directory (Template), the service behind the FME Flow Azure AD web connection has now moved the scopes for the Token request from the URL to the Request Format. This change ensures those scopes persist when you refresh your access token for Flow and other services, but it differs from previous configurations, which I believe is what's happening. 

For now, you’ll have to move scope=<your-scopes> out of the URL and into the Request Format, or remove the placeholder completely if no scope was set.

So the Retrieve Token Parameters> Request Format  should look something like:
code=[CODE]&client_id=[CLIENT_ID]&redirect_uri=[REDIRECT_URI]&grant_type=authorization_code&scope=

If this doesn’t help, please open a ticket with us using this link: Support Case.

We can give you more targeted guidance by seeing the web service you’ve configured in FME and the scopes your sys admin has placed on the App registration 🙂

[FMEENGINE-88618]

I’m having very similar issues, same error message as from the original post, and our ORG just migrated to 2026.3 this week.
I’ve modified the Retrieve and Refresh token formats based on the suggestions in this post.

My format (Retrieve token Parameters) now looks like:
code=[CODE]&client_id=[CLIENT_ID]&redirect_uri=[REDIRECT_URI]&grant_type=authorization_code&scope=User.Read

I’m able to use the modified template to successfully login to Flow via Azure, but I think something is still not configured properly because the token is expiring within an hour or two, the connections I keep making work for a while but then stop leading to making yet another connection.

Any ideas, or is a support ticket the way to go?
Cheers

Chad

Hi all,

We're seeing the same problem after upgrading to FME Form 2026.3.1.1. Our web connections that use Azure AD (Microsoft Entra ID) to authenticate against our FME Flow instances (DV/QA/PR) stopped working after the upgrade.

The web services are created from the Microsoft Azure Active Directory (Template). After the upgrade, the web service definition has a new mandatory field: Redirect Strategy. Our setup:

• Client ID

• Redirect URI: http://localhost

• Redirect Strategy: Loopback Interface Redirect

• Authorization URL: https://login.microsoftonline.com/`<tenant-id>/oauth2/v2.0/authorize?response_type=code&scope=offline_access `https://graph.microsoft.com/User.Read

• Token URL: ```https://login.microsoftonline.com/``<tenant-id>/oauth2/v2.0/token?scope=[OAUTH_SCOPE]`

• Request format: code=[CODE]&client_id=[CLIENT_ID]&redirect_uri=[REDIRECT_URI]&grant_type=authorization_code&scope=[AUTHORIZATION_SCOPE]

• PKCE: disabled
  
   

  Error with Loopback Interface Redirect
  When we test the web service, we get:

  Unable to retrieve access token for web service 'FME FLOW AZURE DV'
  HTTP 400 Bad Request: {"error":"invalid_grant","error_description":"AADSTS65001: The user or administrator has not consented to use the application with ID '<app-id>' named 'FMEFLOW instance'. Send an interactive authorization request for this user and resource." ... "error_codes":[65001], "suberror":"consent_required"}

   

  Interesting observation (possible workaround / root cause hint)
  If the web service in the previous FME Form installation had https://localhost as the Redirect URI, the existing connection keeps working after the upgrade. But because Redirect Strategy is now mandatory, you have to set it before you can test or edit the web service, and doing that resets the Redirect URI to http://localhost. From that point on, the web service no longer works.

  So it looks like the switch from https://localhost to http://localhost (forced by the new Redirect Strategy field) could be related to the consent/redirect mismatch on the Azure side, even though permissions are granted in the app registration.

Hi all,

We're seeing the same problem after upgrading to FME Form 2026.3.1.1. Our web connections that use Azure AD (Microsoft Entra ID) to authenticate against our FME Flow instances (DV/QA/PR) stopped working after the upgrade.

Interesting observation (possible workaround / root cause hint)
If the web service in the previous FME Form installation had https://localhost as the Redirect URI, the existing connection keeps working after the upgrade. But because Redirect Strategy is now mandatory, you have to set it before you can test or edit the web service, and doing that resets the Redirect URI to http://localhost. From that point on, the web service no longer works.

So it looks like the switch from https://localhost to http://localhost (forced by the new Redirect Strategy field) could be related to the consent/redirect mismatch on the Azure side, even though permissions are granted in the app registration.

I’m sorry you folks are having trouble connecting to FME Flow!

​@chadprop I’d say a support ticket is the best way for us to dig into these issues. Here’s a link to open a support case: Support Case. When you do submit that case, please share your exact FME version and build for both FME Form (Help>About FME) and Flow, as well as a screenshot of your configured web service.

The official workaround is mentioned here for context: Known Issue>Azure Active Directory (Template) Web Service.

​@francis I haven’t been able to tie the AADSTS65001 consent required error to the redirect strategy yet, but that’s worth digging into a support case as well.

Again, I’m sorry you folks are running into issues here! We’ll update this thread as we learn more about these connection and token expiration issues

Desiree,
I removed the scope=parameter from both the retrieve and refresh URLs.
Oddly enough, adding the scope to the Request Formats for both and using “scope=https://graph.microsoft.com/User.Read” appears to work as I’ve now been able to stabilize the connection to Flow and it persists beyond a full day of use.
Thanks for the link to the workaround as it was helpful with the formatting.

Cheers

Chad