Adding fix for OBO cache key error in long running OBO with DefaultAuthorizationHeaderProvider

[trwalke]

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

Description

Updates the DefaultAuthorizationHeaderProvider to update the AcquireTokenOptions.LongRunningWebApiSessionKey after the token is acquired so that the key can be used in the next OBO call.

Fixes #3382

[jmprieur]

Wouldn't it be better to use the new interface that Keegan created:

https://github.com/AzureAD/microsoft-identity-abstractions-for-dotnet/blob/main/src/Microsoft.Identity.Abstractions/DownstreamApi/IAuthorizationHeaderProvider_T.cs

this way we could return something?

[trwalke]

Wouldn't it be better to use the new interface that Keegan created:

https://github.com/AzureAD/microsoft-identity-abstractions-for-dotnet/blob/main/src/Microsoft.Identity.Abstractions/DownstreamApi/IAuthorizationHeaderProvider_T.cs

this way we could return something?

I'm am not sure it is the best way to do it. The returning of the cache key also happens when using the ITokenAcquisition so I wouldn't want to limit the solution to only IAuthorizationHeaderProvider_T.

See https://github.com/AzureAD/microsoft-identity-web/wiki/get-token-in-event-handler#principle

Lets fix this for the customer since it is the currently released behavior and change the design in a follow up PR. I can create a work item.