.Net: Bug: .NET api-key header not sent - OpenAIChatCompletion not working with Azure AI Foundry deployments

[py6080]

Describe the bug
api-key header is not being sent when using the AddOpenAIChatCompletion Kernel extensions. Instead an Authorization: Bearer * header is being sent which does not work with Azure AI Foundry deployments - they require an api-key header.

To Reproduce
Steps to reproduce the behavior:

1. Register an OpenAI chat client:

            services.AddOpenAIChatCompletion(
                modelId: modelId,
                serviceId: modelId,
                openAIClient: new OpenAIClient(
                    credential: new ApiKeyCredential(
                        apiKey
                    ),
                    options: new OpenAIClientOptions
                    {
                        Endpoint = new Uri(endpoint)
                    }
                )
            );

2. Obtain it and send a request:

        var chatModel = _semanticKernel.GetRequiredService<IChatCompletionService>(chatModelInfo.ModelId);
        var response = await chatModel.GetChatMessageContentAsync(
                    chatHistory: _chatHistory,
                    kernel: _Kernel);

3. The request will fail with a 401 Unauthorized

Expected behavior
api-key header should be sent

Platform

• Language: C#
• Source: v. 1.3.6
• AI model: Phi-3-small-8k-instruct

Additional context
Obviously it can be worked around with a custom HTTP client that's sending the correct header, but this being a Microsoft-supported package it should integrate with Microsoft products seamlessly.

The URL https://.services.ai.azure.com/models is passed to the endpoint parameter.
From the official docs it would seem that this is supported out-of-the-box, but it's not. https://learn.microsoft.com/bg-bg/azure/ai-foundry/model-inference/concepts/endpoints?tabs=csharp#routing

[py6080]

Also tried AddAzureOpenAIChatCompletion. While it sends the correct api-key header

Request headers:

...
 Semantic-Kernel-Version: 1.36.1.0
 api-key: <API-KEY>
...

it generates a different URL from my inference endpoint - https://.services.ai.azure.com/models/openai/deployments/Phi-3-small-8k-instruct/chat/completions?api-version=2024-10-01-preview

With AddOpenAIChatCompletion the following endpoint is generated: https://.services.ai.azure.com/models/chat/completions?api-version=2024-05-01-preview which works if requested with the api-key header

I tried searching for documentation, but can't find anything that describes the usages of these extension methods and their overloads.

[py6080]

A serverless Phi-3-small-8k-instruct deployment works out-of-the-box with this experimental extension method

(extension) IServiceCollection IServiceCollection.AddOpenAIChatCompletion(string modelId, Uri endpoint, [string? apiKey = null], [string? orgId = null], [string? serviceId = null]) (+ 2 overloads)

the serverless deployment expects an Authorization header

[dmytrostruk]

@py6080 Thanks for reporting this issue!

Obviously it can be worked around with a custom HTTP client that's sending the correct header, but this being a Microsoft-supported package it should integrate with Microsoft products seamlessly.

I agree. I think we can provide a fix on Semantic Kernel level, but if we do that, it still won't work for developers who directly use OpenAI SDK. Maybe it would be better to fix it on underlying SDK level, so more developers can benefit from it.

[py6080]

It looks to me like it should be fixed on the underlying level as well. In the mean time maybe it's a good idea for a reference to be added on how the issue can be worked around or at least to be pointed out that it's possible for a discrepancy to arise.

[dmytrostruk]

Obviously it can be worked around with a custom HTTP client that's sending the correct header, but this being a Microsoft-supported package it should integrate with Microsoft products seamlessly.

Now as I more think about it, taking into account that it's OpenAIClient, we can't really update it on OpenAI .NET SDK level, since underlying SDK shouldn't be aware of Azure AI Foundry or any other OpenAI-compatible endpoints and their authentication mechanisms. That's usually the case where custom HTTP client can fix this.

In scope of this issue, we will add an example how to use OpenAI connector with Azure AI Foundry deployments.

[py6080]

It makes sense, in my mind actually AzureOpenAI client was the correct client to use.
It would be good to note in the documentation which client can be used with which Azure deployment.
Of course, you are right that OpenAI client should be agnostic to the specific model deployment as long as it has a compatible interface.