Azure-sdk-for-net: ClientServerCredential equivalent for simple apiKey authentication?

[stefanvalianu]

Is there support for swagger's concept of apiKey auth? The premise is simple; include an apiKey in a named parameter either as a header or a query parameter. Incidentally, this is our team's primary form of providing clients with auth (as opposed to oauth or basic auth).

Usage is very straight forward, adding this form of authentication to a request either requires adding a url parameter (&authenticationParameterName=authenticationParameterValue) or as a header (AuthenticationHeaderName: AuthenticationHeaderValue).

Looking to use it as part of autorest authentication for clients that don't have either oauth or basic auth support; issue called out here (and was redirected to this repo):

https://github.com/Azure/autorest/issues/2431

[shahabhijeet]

@stefanvalianu we have not got any such request so far, plus all azure services uses oAuth/oAuth2
So we will have to discuss this in our next planning to add support for it.
In the mean time, have you considered adding customization to your generated client that accepts APIKey?
Have you explored that option to add functionality that will allow your client to accept ApiKey.

[stefanvalianu]

Yup, that's exactly the approach I took, just implemented my own ServiceClientCredentials for apiKey. Just saying, to make the autorest library useful for scenarios beyond azure, this would be a helpful feature to have out-of-the-box (and the code is very simple).

[heldersepu]

@stefanvalianu Can you share the code to your own ServiceClientCredentials for apiKey...
I'm running into this same issue...

[heldersepu]

Here is my version of the ServiceClientCredentials for apiKey

c# class ApiKeyCredentials : ServiceClientCredentials { public override Task ProcessHttpRequestAsync(HttpRequestMessage request, CancellationToken cancellationToken) { request.Headers.Add("apiKey", "123456"); return base.ProcessHttpRequestAsync(request, cancellationToken); } }

[MartinF]

Just want to add that I have had the same need for apikey authentication support, and expected it to be included since it is a common scenario and supported by Swagger.

Considering that the "Add -> Rest API Client" Feature in Visual Studio uses this library, and thereby may be used to generate client proxy code that is not targeting Azure, I think it would make sense to include it, even though your focus might only be to support Azure.

UPDATE: After inspecting the issue some more, it might make sense to use the already existing TokenCredentials instead, which will set the Authorization header and allow for a scheme/type to be specified and add support for multiple ways of authorization.

[jacobmohl]

Following this issue as well.

Cant get the TokenCredentials to work with Azure API Management where we need either a header with name "Ocp-Apim-Subscription-Key" or a query parameter named "subscription-key". Do anyone have code samples for this?

[Cloudmersive]

This is so crappy that you don't have this. Why is this not added yet??

[scottrangerio]

I've just ran into this issue when trying to generate a client for an Azure Function app. By default, Azure Functions use API keys which need to be passed either in the header or the query string. With that, this would be a nice to have to make generating clients for function apps more seamless.

In the mean time, I was able to work around the issue using the solution above

public class FunctionKeyCredentials : ServiceClientCredentials
{
    private readonly string key;

    public FunctionKeyCredentials(string key)
    {
        this.key= !string.IsNullOrWhiteSpace(key)
            ? key
            : throw new ArgumentNullException(nameof(key));
    }

    public override Task ProcessHttpRequestAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        request.Headers.Add("x-functions-key", key);
        return base.ProcessHttpRequestAsync(request, cancellationToken);
    }
}

[Petermarcu]

@schaabs thoughts on this one?

[schaabs]

I can't speak to the Track 1 autorest generator, but for Track 2 generated libraries based off Azure.Core I'd imagine it would be pretty straight forward to add support for this. We recently added support for it in Azure.Core in this PR https://github.com/Azure/azure-sdk-for-net/pull/10668 for cognitive services which optionally authenticate with API keys.

@pakrym or @MiYanni would have a better idea of the cost of adding this to the generator.

[pakrym]

We are only generating authentication constructors for management plane APIs where authentication options are more-or-less well defined (AAD with TokenCredential) for now the data-plane client authors are on their own having to define constructors for heir clients.

Adding the generator feature is not very hard if we find a consistent way of representing the requirements in swagger. cc @johanste

[johanste]

@schaabs, is there anything missing from the security scheme object that prevents us from making the determination for client constructors based on that?

[schaabs]

@johanste We're discussing how to best to consume the swagger security scheme to properly generate clients with the proper authentication scheme. For API key authentication this would be sufficient.

[AlexGhiondea]

Looks like we have what we need here. Closing.

[drdamour]

@AlexGhiondea sorry, confused, was this added, or is there another master ticket tracking this effort?