[QUERY] Creating custom client with AddClient() in AddAzureClients() using ClientSecretCredential and ClientOptions

Library name and version

Azure.Identity 1.9.0

Query/Question

What is the correct approach when calling a daemon when using a custom client. I would like to use the Azure.Identity package and use it’s client builder. Because this will manage the lifetime of the token.

The thing is that the AddClient method needs a class that inherits ClientOptions, but what purpose does it have? In this use case. Or is there an alternative?

A few observations:

• If I provide a custom class it must inherit ClientOptions and must be registered in the DI,
• The AddClient TOptions does not enforce it to be inherited by ClientOptions It will fail when not inherited with ClientOptions . (Constructor on type ‘MyCustomOptions’ not found.)
• I could also use SecretClientOptions, which works, but it does not feel ok, because it could have side effects.

I use MyTokenKeeper in the DelegatingHandler of a HttpClient to fill the Authorization header. That’s the only thing I need in this use case.

            services.AddAzureClients(clientBuilder =>
            {
                clientBuilder.UseCredential(serviceProvider =>
                {
                    var myOptions = serviceProvider.GetRequiredService<myOptions>();
                    return new ClientSecretCredential(myOptions.TenantId, myOptions.ClientId, myOptions.Secret);
                });
                clientBuilder.AddClient<MyTokenKeeper, MyTokenKeeperClientOptions>((options, tokenCredential, serviceProvider) =>
                {
                    var myOptions = serviceProvider.GetRequiredService<MyOptions>();
                    var token = tokenCredential.GetToken(new TokenRequestContext(new[] { myOptions.Scope }), CancellationToken.None);
                    return new MyTokenKeeper(token.Token);
                });
            });

[jsquire]

Hi @spiral-dev. Thanks for reaching out and we regret that you’re experiencing difficulties. Your observations are accurate - the AzureClientFactoryBuilder is intended to build Azure SDK clients and assumes the conventions that they must use. It is not intended to be general purpose DI infrastructure, though there’s intentionally nothing that prevents you from using it that way. In your scenario, you are constructing a type that is not an Azure SDK client and does not follow those conventions. As a result, there’s a misalignment between the what your token keeper needs and the signature of the method.

Can you help me understand why you’re using the Azure Client extensions if you only need to register a token? Is there a reason that you chose not to just create the token and register it with DI?

services.AddSingleton<ClientSecretCredential>(serviceProvider=>
{
    var myOptions = serviceProvider.GetRequiredService<myOptions>();
    return new ClientSecretCredential(myOptions.TenantId, myOptions.ClientId, myOptions.Secret);
});

To answer your specific question - there is no purpose to the ClientOptions in your scenario. If you’d like to continue using the Azure client intrastructure, I’d suggest just asking for an Azure client options type and ignoring it. There’s no potential side-effects for having an options type created - they’re just simple data transfer models. In this scenario, ClientSecretCredentialOptions would seem to be reasonable, as you mentioned.

clientBuilder.AddClient<MyTokenKeeper, ClientSecretCredentialOptions>((_, tokenCredential, serviceProvider) =>
{
    var myOptions = serviceProvider.GetRequiredService<MyOptions>();
    var token = tokenCredential.GetToken(new TokenRequestContext(new[] { myOptions.Scope }), CancellationToken.None);
    return new MyTokenKeeper(token.Token);
});

[github-actions[bot]]

Hi @spiral-dev, since you haven’t asked that we /unresolve the issue, we’ll close this out. If you believe further discussion is needed, please add a comment /unresolve to reopen the issue.