Improve observability of Microsoft.IdentityModel logs

[halter73]

If you use an authentication handler from Microsoft.Identity.Web, it will wire up Microsoft.IdentityModel logs with Microsoft.Extensions.Logging using IdentityLoggerAdapter. The authentication handlers we ship out of this repo (JwtBearerHandler, OpenIdConnectHander, and WsFederationHandler) don't do this.

Currently, to get logs from IdentityModel like "IDX10214: Audience validation failed." from the JwtBearerHandler into your ASP.NET Core loggers, you have to do something like the following after adding a new package reference to Microsoft.IdentityModel.LoggingExtensions:

var loggerFactory = app.Services.GetRequiredService<ILoggerFactory>();
var logger = loggerFactory.CreateLogger("IdentityLogger");
LogHelper.Logger = new IdentityLoggerAdapter(logger);

Setting the static LogHelper.Logger property the way Microsoft.Identity.Web does in methods like AddJwtBearer is far from ideal. We should work with the Identity team to add APIs to components like JsonWebTokenHandler and ConfigurationManager so they log to a non-static IIdentityLogger provided by our authentication handlers.

This could be used to improve the Microsoft.Identity.Web integration with ASP.NET Core logging as well by allowing log messages to be scoped to the handler that is logging and include things like the whether the log came from AddMicrosoftIdentityWebApp or AddMicrosoftIdentityWebApi.

@jennyf19 @keegan-caruso

[halter73]

This is similar to AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet#1778, but it looks like some progress has been made since then with the addition of IdentityLoggerAdapter. I don't know if that needs its own assembly, but maybe a middle ground would be to introduce a AddIdentityLoggerAdapter API to Microsoft.IdentityModel.LoggingExtensions and have all the handlers call that. That wouldn't be nearly as good as being able to provide a unique logger from each authentication handler, but it would be better than what we have now.