Is it possible to customize the endpoint used for /token calls?

[mrichards3]

We would like to route calls from internal services to Azure AD through an internal API gateway. Is it possible to customize the URL that this library uses for /token calls?

For example, if I configure my application as such:

appsettings.json
...
"AzureAd": {
  "Instance": "https://login.microsoftonline.com/",
  "TenantId": "<redacted>",
  "ClientId": "<redacted>",
  "ClientCertificates":[<redacted>]
},
"SecureService": {
  "BaseUrl": "https://secureservice.azurewebsites.net",
  "Scopes": "api://secureservice.azurewebsites.net/.default"
},
...


Startup.cs (ConfigureServices method)
...
services
  .AddAuthentication().AddMicrosoftIdentityWebApi(Configuration)
    .EnableTokenAcquisitionToCallDownstreamApi()
      .AddDownstreamWebApi("SecureService", Configuration.GetSection("SecureService"))
    .AddInMemoryTokenCaches();
...

At runtime, an HTTP call like this is made to acquire a token:

POST https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token

Instead, I would like the call to be made to an internal URL like this:

POST https://<my.internal.gateway.host>/azuread/<tenant>/oauth2/v2.0/token

The internal gateway server would forward the request to login.microsoftonline.com and then return the response back to my application.

Is this type of setup possible using this library?

[jmprieur]

@mrichards3
Did you try to change the Instance in the appsetttings.json?

[mrichards3]

I can try that and see if it works.

I noticed that this flow is posting a client_assertion field as one of the parameters to the /token endpoint, and that contains a JWT with the audience set to:

"aud": "https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token",

Will this field be altered if the Instance setting is changed, and would that cause Azure AD to reject the JWT in the client_assertion?

[jmprieur]

yes it will. See https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-net-client-assertions#signed-assertions
Alternatively you might want to use a proxy / reverse proxy?

[mrichards3]

@jmprieur - After looking at this a bit closer, the proxy server configuration maybe isn't as straightforward as I hoped.

I see that IHttpClientFactory is injected into the TokenAcquisition service here:

https://github.com/AzureAD/microsoft-identity-web/blob/master/src/Microsoft.Identity.Web/TokenAcquisition.cs#L68

This doesn't look like it is using named clients or any other mechanism to customize the HttpClient specifically to this service. So to utilize a proxy server, I think we would need to set customize the default HttpClient globally within our service, right?

https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient.defaultproxy?view=netcore-3.1

The token acquisition is the only call we want to go through a proxy server, so we will need to make sure all other endpoints that our service calls are set in the proxy bypass list.

[mrichards3]

Just to close the loop on this thread, we were able to successfully configure our application to perform the token acquisition step through an HTTP proxy server.

[penenkel]

@mrichards3 May I ask how you managed to configure the token acquisition to use a proxy? I can't seem to find such an option.

[mrichards3]

@penenkel We configured the DefaultProxy for all HTTP clients in the app as shown here:

https://learn.microsoft.com/en-us/dotnet/api/system.net.http.httpclient.defaultproxy?view=net-7.0

We had to set the BypassList on the proxy to explicitly not use the proxy for all of the other traffic from the app not destined for Azure AD.

[penenkel]

@mrichards3 Thank you.

I figured out an other workaround if anyone is interessted:
By decorating the IHttpClientFactory one can intercept all requests for the default HttpClient (i.e. the HttpClient named "") and replace them with a request for a suitable named instance. This requires that either Microsoft.Identiy.Web is the only service requesting the default HttpClient (i.e. all other services must use named/typed HttpClients) or that one inspects the StackTrace if a method unique to the MSAL/Identity.Web library is in it.

PS: Microsoft.Idenitiy.Web should really switch to using a named HttpClient or depend on the specialized IMsalHttpClientFactory instead of the generic IHttpClientFactory.

[mrichards3]

Alternatively, if we could call Azure AD through a Private Endpoint (w/ Private Link), that would get us around the gateway/proxy issue entirely. That doesn't seem to be a capability that Azure AD offers today.