[Feature Request] Offer a message handler approach with ITokenAcquisition

[rellis-of-rhindleton]

MSAL Angular uses a "protected resource map" approach to handle multiple downstream APIs. With the ITokenAcquisition service you're just a few steps away from being able to do the same thing.

I wanted to use the Http message handler approach in a project and set up a couple of (very) simple classes to handle it. Passing it along. If it doesn't fit the needs of the library, no worries.

Stripped-down example:
https://github.com/rellis-of-rhindleton/token-acquisition-handler

(That example uses a custom Graph client, I know that's redundant but I wanted a working example.)

[jmprieur]

@rellis-of-rhindleton : what about IDownstreamWebAPI? doesn't it do something similar?

[rellis-of-rhindleton]

I want to use the typical/idiomatic HttpClient configuration approach in Startup.cs. IDownstreamWebAPI seems to not allow that sort of customization. I may have missed something, though.

Using ITokenAcquisition it’s easy to build a simple handler that gets a token as needed for a downstream resource, which can be plugged in to the configuration of an HttpClient along with whatever other handlers might be needed. It’s easy to do myself. I just figured the project is very close to it already and maybe could do something similar out of the box.

services.AddTokenAcquisitionHandler(
    Configuration.GetSection("DownstreamApiA"),
    Configuration.GetSection("DownstreamApiB")
);

services.AddHttpClient<DownstreamApiA>(client =>
    {
        // client options
    })
    .AddHttpMessageHandler<TokenAcquisitionHandler>()
    .AddHttpMessageHandler<SomeOtherHandler>();

[jmprieur]

@rellis-of-rhindleton. I understand better. Thanks for clarifying. So I think it's a duplicate of https://github.com/AzureAD/microsoft-identity-web/issues/1131

BTW, in https://github.com/rellis-of-rhindleton/token-acquisition-handler#appsettingsjson-or-other-configuration, I don't understand why would would want you express which flow to use? Microsoft.Identity.Web abstracts this out for you, you don't need to know if this is OBO, Auth Code Flow, silent flow, refresh, etc ... you only have to choose between a user-flow or an app-only-flow.

[rellis-of-rhindleton]

It does seem to be the same, yes.

I’m not sure I understand the list of options you posted in your comment there... I would only suggest that the handler be available for use without too much abstraction surrounding it. I’m a fan of convenience classes when appropriate, but the need to plug in multiple handlers and control HttpClient configuration seems to come up a lot.

As far as specifying the flow — that was just my attempt at explicit configuration, and not really necessary, you can ignore it. My first draft chose app-or-user automatically by checking the scope for “/.default” (and throwing an exception if there was more than one). Changed it to be more explicit because of my personal circumstances — I’ve been trying to teach OAuth to a lot of people lately and it’s complicated.

[jennyf19]

This was included in 1.15.0 release.