Authentication Issues with HTTP API Built-In Requests for Azure Durable Function Hosted in Azure Container App (Isolated Mode)

[MarkOwen-CoditMT]

Description:

I am running an Azure Durable Function in isolated mode within an Azure Container App and encountering issues with authenticating API calls using Azure Active Directory (AAD) tokens. Normally, the Durable Functions API endpoints include a code query parameter as part of the request URL for authorization (i.e., statusQueryGetUri, sendEventPostUri, etc.). However, since the function is hosted in a container app, there is no master key available, which makes using the code parameter for access control impossible. I am trying to use an AAD-issued access token instead, but this approach has not worked successfully across endpoints.

Steps to Reproduce:

1. Deploy an Azure Durable Function in isolated mode inside an Azure Container App.
2. Configure AAD-based authentication using an Azure App Registration.
3. Make an API call to the function's statusQueryGetUri, sendEventPostUri, or similar, passing an AAD access token generated by the App Registration instead of the code parameter.

Expected Behavior:

The Durable Functions API should accept an AAD access token for authentication in place of the code parameter when hosted inside an Azure Container App.

Actual Behavior:

The access token does not authorize the requests, and using the code parameter is not an option due to the absence of a master key in the container app environment.

Additional Context:

• Scope and Audience: I have attempted generating tokens with audiences such as api://<principal-id> and https://management.azure.com/, but none have allowed for successful authentication.

• Managed Identity: The Azure Container App is configured with a managed identity, but this has not resolved the issue.

• Platform Details:

<PackageReference Include="Microsoft.Azure.Functions.Extensions" Version="1.1.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.OpenApi" Version="1.5.1" /> <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.22.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.15.1" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.3.0" /> <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" /> <PackageReference Include="Microsoft.Extensions.Azure" Version="1.7.3" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.DurableTask" Version="1.1.7" />

Request:

Is there a recommended approach or best practice for AAD-based authentication on Durable Functions API calls hosted within an Azure Container App running in isolated mode? Should additional permissions or configurations be applied to allow AAD tokens to serve as valid authentication for these function endpoints?

N.B - not sure if its related to #2948

N.B (2) - It says Managed Identity, 1 year later still needs to be implemented? - #2653 (comment)

[cgillum]

Quick clarification: the URLs you're referring to don't use the master key. Rather, they use a system key which is scoped to just the Durable extension.

The Durable Functions API should accept an AAD access token for authentication in place of the code parameter when hosted inside an Azure Container App.

Unfortunately, this isn't how the integrated AAD (Entra ID) authentication works. The functions runtime doesn't accept AAD credentials as a replacement for API keys. Rather, it's expected that authenticated requests to these extension-specific endpoints contain BOTH an AAD credential and an API key. Same for HTTP-triggered functions that accept a function key for authorization.

FYI @mattchenderson

Normally, the Durable Functions API endpoints include a code query parameter as part of the request URL for authorization (i.e., statusQueryGetUri, sendEventPostUri, etc.). However, since the function is hosted in a container app, there is no master key available, which makes using the code parameter for access control impossible.

I'm not aware of anything in Azure Container Apps that would prevent API key functionality from working. That would be a big problem for a lot of people if it weren't. Can you explain how you determined that API keys (including system keys or master keys) aren't available in Container Apps?

[MarkOwen-CoditMT]

Hi @cgillum,

Thank you for your prompt reply and detailed explanation.

Thanks for the clarification. I double-checked with an existing environment where we have our previous standalone hosted functions. As you mentioned, in this case, the System Key is listed under the App Keys tab as a durable_extensions key.

In our current setup, the Azure Function is hosted in an Azure Container App. This setup means that, at a high level, the App Keys are not directly hosted or listed for the Azure Function, and I believe they would not appear in the host.json file (please correct me if I’m wrong—I hope I am!). From various threads I’ve read, the workarounds I found typically involve manually adding the master keys to host.json, as mentioned here: Azure/azure-functions-host#4147.

This might be somewhat off-topic, as it specifically discusses the master key, but I’m not sure if the System Key would also be affected in the same way.

My main question is:

If an Azure Function is hosted within a container app and includes a host.json file, will a System Key still be generated for the function?

If the answer is yes, once the change in this issue is merged (Azure Functions Durable Extension Issue #2810), will it provide a way to retrieve the System Key’s value, potentially solving my problem?

Scenario

We’ve made a business decision to migrate from standalone functions to functions running within an Azure Container App.

Since managing master keys in host.json files within containers can be chaotic, we decided to enable the Authentication tab and authenticate requests to the function via an app registration.

This approach works well: all first-level HTTP-triggered requests to the function, as well as calls to activity functions within this durable function, are authenticated successfully.

The issue I’m facing is specifically with calling the runtime durable task endpoints, where authentication fails.

As you mentioned above, we need to include the System Key in these requests (which I suspected) instead of using the access token alone.

I hope this clarifies the scenario and the issue sufficiently. Thank you again for your assistance.

[MarkOwen-CoditMT]

@cgillum ,

The above issue has been fixed by the new azure functions durable tasks release 1.2.0 the CreateHttpManagementPayload method returns the code (system key value). all that remains since the url will be in localhost is to update it to base url of your container app url. If you have auth settings enabled like in my case, you need to also pass the access token in the header for both auth and the local authentication to work.