API Connection returns 400 "Bad Request" when Logic App and Connection was created in VS Code

[rockenstein]

Dear all,

I was trying to create a Logic App (Standard) that simply sends an email via SMTP API Connection when the Logic App is called via Http webhook.

Since the scenario we are working in demands the use of Terraform IaC deployment, I created and Deployed my Logic App in a Terraform configuration. Afterwards, I created a Logic App (Standard) project in Visual Studio code and created a workflow, including the API Connection to my smtp test server. After deploying the project to my Logic App (Standard) resource via VSCode, I triggered the workflow and got a 400 "Bad request" when the SMTP Send Email action tried to call the API Connection.

{ "status": 400, "source": "https://logic-germanywestcentral-001.token.azure-apihub.net:443/tokens/logic-apis-germanywestcentral/8af2fb4fc6724ebc/smtp/a09a483c3c************************/exchange", "message": "Error from token exchange: Invalid Authorization header. Authorization header is expected in the form 'Bearer token' or 'Key token'." }

When I created the Logic App (Standard) in the Azure Portal (same subscription, same storage account, same App Service Plan), the connection works just fine.

An ARM template export shows a difference between the resource deployed by Terraform and Logic App project in VS Code (Left side of the images) and the resource I created in the Azure Portal (right side), although the portal view shows no difference.

Is there any special way of handling the workflows/connections if they are deployed with VS Code?

[shailesh-agre]

Checking with the product group if it has been reported.

[klawrawkz]

Hi, my name is klawrakz. I am fine. How are you?

I'm not a Microsoft employee, but I play one on TV.

The following is solely MY OPINION. Nothing in this statement should be read as implying or intimating anything other than an end user architect sharing some hard-fought, hard-to-find, experience-based, battle-tested, opinionated, bona fide observations regarding logic apps generally, and logic app connections more specifically.

Onward and upward.

IMHO: Logic apps are not suitable for automated enterprise deployment in the manner you describe. By automated I mean any modern approach by which working code is released to an environment using a mechanized approach that excludes human intervention or interference once the process has been defined, implemented, and tested. AKA any variety of modern devops.

My understanding of logic app connections is the following. Many logic app connections rely on Azure Active Directory Open Authentication (Azure AD OAuth). Azure AD OAuth connections need to be MANUALLY authenticated or reauthenticated in the Azure portal to acquire a new access token. There are other mechanisms, but the portal is the easiest and recommended way to work with Azure AD OAuth authentication. For more details google logic app connectors overview, and single tenant authentication. Also check links included below.

It is for this, or a similar, reason that your connections are not working. If you deploy the logic app via any modern enterprise approved technique, e.g. devops automation, or in your case via vs Code, you need to deploy the logic app WITHOUT connections. Then in the azure portal, you MANUALLY open each logic app you deployed via your automated best practice. Manually, you know, BY HAND, and probably against enterprise best practice guidance, open the logic app under study in the azure portal logic app "designer." Once you have opened your logic app, you will notice red exclamations pointing out what you already know. Your connections "need some attention." In your Azure landing zone, MANUALLY create a new connection for each step in your logic app that requires a connection. Save the changes. Wash, Rinse, Repeat for all the logic apps you have deployed via automation.

The NEXT time you deploy the SAME logic apps via automation or vs Code, the connections will be valid since you manually validated them (we must repeat) BY HAND, you know, MANUALLY, the first time you deployed them. Again, you are NOT deploying logic apps with connections. You are deploying denatured logic apps with placeholders for connections. Hence, after a second, third, fourth, and so on, deployment, you do not overwrite the connections that you initially MANUALLY validated using the portal logic app designer after the initial deployment. Thus, your automated deployment (via devops/vs Code) should work fine after the FIRST deployment and MANUAL connection validation operation is complete.

You can find more information about logic apps and connections here, and here.

[shailesh-agre]

@rockenstein This could be an issue with the connetions.json. Can you share the connections.json and workflow.json contents? And also when you create the connections using Terraform, did you access policies for the connection?

[ptsouk]

Hello, I am having a similar issue. My scenario is to deploy an ARM template with all the necessary resources (including the connections) and then to use VS Code to upload my workflow to the logic app. When the logic app is triggered it fails with the following on the activity that failed:

{ "status": 400, "source": "https://logic-apis-westeurope.token.azure-apim.net:443/tokens/logic-apis-westeurope/3fe4afc3390d30b2/wdatp/567598a2d9c84097bd1863b4ea5e809c/exchange", "message": "Error from token exchange: Invalid Authorization header. Authorization header is expected in the form 'Bearer token' or 'Key token'." }

@shailesh-agre have you found other similar cases ? Do we have any update ?

Thanks!

[esdccs1]

I have this issue as well when making outlook action nodes in a workflow, then deploying the workflow to a Logic App (Standard):

{

  "status": 400,

  "source": "[https://logic-apis-canadacentral.token.azure-apim.net:443/tokens/logic-apis-canadacentral/XXXXXXXX/office365/XXXXXXXXXXXXXXXX/exchange"](https://logic-apis-canadacentral.token.azure-apim.net/tokens/logic-apis-canadacentral/XXXXXXX/office365/XXXXXXXXXX/exchange%22),

  "message": "Error from token exchange: Invalid Authorization header. Authorization header is expected in the form 'Bearer token' or 'Key token'."

}

I create the connection in VSCode, then upload the entire project via a - task: AzureFunctionApp@1 in a azdo pipeline

[klawrawkz]

Hi, my name is klawrakz. I am fine. How are you?

Well gosh, this issue has only been open for over 2 (TWO) years, and there seems to be no urgency from Microsoft to offer help or advise.

I must say that I find this seeming lack of concern a bit, just a little bit repugnant. Perhaps I'm underestimating the totalitarianism of the repugnancy just to be nice? :)

Here's an idea.

1. Make sure that you create a Managed Service Principal for the App Service host environment that "runs" your logic app.
2. Make sure you are using Managed API Connections e.g.

            "type": "Microsoft.Web/connections",
            "apiVersion": "2016-06-01",
            "name": "[parameters('connections_queue_name')]",
            "location": "eastus2",
            "kind": "V2",
            "properties": {
                "displayName": "myQueueName-dev",
                "customParameterValues": {},
                "nonSecretParameterValues": {
                    "storageaccount": "<storageAccountName>"
                },
                "parameterValues": {
                    "storageaccount": "<storageAccountName>",
                    "sharedkey": "<blablahblahTSuperPooperSecretCodeHere8fV+sJqpNGjZ==>"
                },
                "api": {
                    "name": "azurequeues",
                    "displayName": "Azure Queues",
                    "id": "/subscriptions/<subscription>/providers/Microsoft.Web/locations/<location>/managedApis/azurequeues",
                    "type": "Microsoft.Web/locations/managedApis"
                }
            }
        }

3. Make sure the connections.json file is using ManagedServiceIdentity for the auth type e.g.

"azureblob-dev": {
      "api": {
        "id": "/subscriptions/<subscription>/providers/Microsoft.Web/locations/<location>/managedApis/azureblob"
      },
      "connection": {
        "id": "/subscriptions/<subscription>/resourcegroups/<rg>/providers/microsoft.web/connections/azureblob-dev"
      },
      "connectionRuntimeUrl": "https://8edef5c8e525a860.11.common.logic-somelocation.azure-apihub.net/apim/azureblob/<guid-like-identifier>",
      "authentication": { "type": "ManagedServiceIdentity" }
    }

4. In your favorite environment, e.g. the Azure Portal, Powershell, AZ CLI, Azure REST API, Postman, etc. make sure that you have created an ACCESS POLICY applicable to the Managed Service Principal in the Managed Connection. Below is a screen shot from the Az Portal.
5. There are Az API calls you can make to try and get this turd ball rolling. It's probably easiest at this point to open up the "UI designer" thing in azure and verify your connection is "working".

Hope everybody's doing well.

klaw

[jjdeventer]

Hi guys,

I had the same problem. What i did was the following:

1. First from Visual Studio add the Action and go through the Authorization flow (in my case i am using the Outlook - Send E-mail from shared mailbox action). Result of this step is the API connection being created in the resource group you selected when adding an Azure action. Under the hood, also two files are being modified: connections.json and local.settings Important part here is the parameter, that is pointing to @appsetting office365-connectionKey. That key is actually added to another file: the local.settings file This is the key that is needed during runtime.

2. When you now deploy the Logic App to your app service plan, that value is not being added to your configuration. You have to do this manually in the Configuration section of the Logic App (in this example in the Azure Portal UI). Add a new Application Setting and name it exactly the same as the @appsetting, in my case office365-connectionKey. The value is the key from the local.settings file mentioned earlier. Don't forget to save! This should do the trick. Now during runtime, the Logic App will fetch the key from the configuration and pass it to the API connection. Hope this helps!

Kind regards,

Jeroen

[tiagoacosta17]

Thanks @jjdeventer ! yesterday also had the same issue with service bus and now this helped.

[klawrawkz]

Nice comment @jjdeventer. Out of curiosity, does this procedure "authorize" the office365 connection such that when you deploy it is not necessary to visit the connection in Azure and click the "authorize" button to enable the connection for use?

Hope everyone is well.

klaw

[jjdeventer]

Nice comment @jjdeventer. Out of curiosity, does this procedure "authorize" the office365 connection such that when you deploy it is not necessary to visit the connection in Azure and click the "authorize" button to enable the connection for use?

Hope everyone is well.

klaw

Hi Klaw, i did not have to authorize it again, so the initial authorization initiated when adding the action in the workflow designer in VSCode was sufficient. Only downside to this approach is thus the manual editing of the configuration once deployed as described in my comment. It probably has to do with the local.settings file being added to the .funcignore file during creation of a Logic App project by default. Maybe if you remove this entry, the appsetting will be added automatically.

In general i am not really happy with the whole mechanism of API connections only being generated during design time (so from within the designer). As we will develop once and deploy the Logic Apps also to test,- and production environments, those API connections (perhaps with authentication with different users then development) need to be created in those environments as well. How to go about this? Does anyone here have some best practices on how to do this? We use Github Actions as CI/CD mechanism and it at least eases and automates the deployment, but these manual interventions for configuring the connectors, is error prone.

Regards,

Jeroen

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 7 days since being marked as stale.