Apache and ExpectContinue header causing calls to token endpoint to reply with empty response

[toresenneseth]

Hi,

We ran into an issue when using OidcClient against IBM Security Verify Access running on the Apache web server. This is the on-prem version of IBM Security Verify, used by large enterprises which runs their own Identity Access Management solutions.

When a call to the token endpoint was made, the reply we got was empty, throwing an exception stating that
Access token is missing on token response.

This only happened on a .NET Framework app, but worked fine on a .NET 5 app.
We traced the issue to having to do with the ExpectContinue header. The default value of the ExpectContinue header when creating a HttpClient is null, however it defaults to true on .NET Framework, but false (or even ignored) on .NET 5/Core.

There's a discussion about this difference
dotnet/runtime#26341

The question is:
Should the ExpectContinue header be explicitly set to false if the runtime is .NET Framework?
https://github.com/IdentityModel/IdentityModel.OidcClient/blob/main/src/OidcClient/Infrastructure/OidcClientOptionsExtensions.cs

I'd be glad to create a PR if everyone agrees on this.

The workaround for now is to create a custom backchannel handler and set the ExpectContinue header to false.
Something like

public class OidcClientBackchannelHandler : HttpClientHandler
{
    protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        request.Headers.ExpectContinue = false;
        return base.SendAsync(request, cancellationToken);
    }
}

And then create the OidcClient like this:

var oidcClientOptions = new OidcClientOptions
{
    ...options,
    BackchannelHandler = new OidcClientBackchannelHandler()                    
};

return new OidcClient(oidcClientOptions);

Note that we also tried to set the default to false using the ServicePointManager, but for some reason that didn't work.

Thanks

[leastprivilege]

The only "right" way to fix these kinds of problems would be to externalize the HttpClient creation. So you could plug-in whatever mechanism and configuration you like.

It is on my to-do list for quite a while I just never found the time. If you want to have a look and propose an approach. feel free.

[leastprivilege]

The workaround for now is to create a custom backchannel handler and set the ExpectContinue header to false.

This is not a workaround btw. This hook is for exactly those situations.

[leastprivilege]

I added a callback to integrate with arbitrary HTTP client creation strategies - would that help?

#327

I am closing this issue - feel free to comment on the PR.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue.