runtime: Setting Authorization header on an HttpClient instance does not work in .NET Core 2.1

I had the same problem and found it was related to an automatic redirect. For a temporary fix, I was able to use the URL I was being redirected to instead. It seems like the authentication header is being lost during the redirect.

If you disable AllowAutoRedirect on the HTTP client, can you check if you’re being redirected?

var handler = new HttpClientHandler()
{
        AllowAutoRedirect = false                
};
var client = new HttpClient(handler);

FYI: 2 weeks ago we released a security fix to remove Authorization request headers from redirects. See dotnet/corefx#32730. .NET Core 2.0 didn’t get the patch because it is out of support as of 10/1.

If anyone hits the problem without redirects being involved, please let us know. That is something we would look into. We would need repro or further details in such case to make progress.

@MelbourneDeveloper I believe Microsoft’s official solution for this at the moment of writing this comment (found on MSDN) is to write your own authentication module, which is not ideal. Our request to a url has a redirect that changes every year, sometimes more than once so it’s unreasonable to use CredentialsCache for our use case.

In my opinion, an option should just be added to not remove headers on redirect.

Aren’t redirects expected to drop authentication header? (from security reasons)

Yes. That behavior is by-design. ‘Authorization’ request headers are removed during redirects.

@karelz , I understand why the security fix was added, but doesn’t this raise another important issue? What if there is some other sensitive header included in the original request. Won’t that get sent as part of the redirect?

Shouldn’t there be a callback on HttpClient or the HttpClientHandler that exposes the headers so that we can add or remove them as necessary?

Are we meant to write handler code on every http call that may redirect as @chrisipeters has demonstrated? That’s very onerous and only deals with the problem after the fact.

PS: This has probably been going on since the early versions of HttpClient / HttpClientHandler and probably has implications for all the different platforms. I think I’m experiencing headers being stripped because of redirects in .NET 4.5. What is Microsoft’s recommended approach to this, and are there long term plans to add a callback to that this problem can be dealt with in a graceful way?

Thanks all, the security change about removing Authorization headers is in fact what was going on in my case. For those still working through it, here’s the code I have - working now: Adapted from: https://stackoverflow.com/a/28671822/5043701

• Only does GET in my case

private async Task<string> MakeHTTPCall(Uri url, AuthenticationHeaderValue authHeader)
        {
            var client = new HttpClient();
            client.DefaultRequestHeaders.Authorization = authHeader;

            var response = await client.GetAsync(url);

            if (response.StatusCode == HttpStatusCode.Unauthorized)
            {
                // Authorization header has been set, but the server reports that it is missing.
                // It was probably stripped out due to a redirect.

                var finalRequestUri = response.RequestMessage.RequestUri; // contains the final location after following the redirect.

                if (finalRequestUri != url) // detect that a redirect actually did occur.
                {
                    // If this is public facing, add tests here to determine if Url should be trusted
                    response = await client.GetAsync(finalRequestUri);
                }
            }

            return await response.Content.ReadAsStringAsync();
        }

Yes. That behavior is by-design. ‘Authorization’ request headers are removed during redirects.

There are ways to preserve them though. That requires using a CredentialsCache object and populating it with credentials assigned to specific Uri paths. Then, assign that object to the HttpClientHandler.Credentials property.

However, manually adding ‘Authorization’ request headers is not a recommended pattern anyways. And those headers will be removed during redirects.

+1 this issue. Didn’t have it it 2.0 but now have it in 2.1.

It seems to work fine when PUTing/POSTing to another .NET Core application. When posting to a .NET Framework (4.6) project the following occurs:

Code:

client.Timeout = new TimeSpan(0, 0, REQUEST_TIMEOUT_S);
client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", Token); // I've tried "Token" as well.
var response = await client.PutAsync(Uri, new StringContent(data, Encoding.UTF8, "application/json"));
if (!response.IsSuccessStatusCode)
{
   var errorResponse = await response.Content.ReadAsStringAsync();
   return false;
}

Server side, I explicitly throw an exception and iterate through the headers. Notice authorization is not even there.

“errorResponse”:

Content-Length= 2239, Content-Type= application/json; charset=utf-8, Cookie= ASP.NET_SessionId=<sessionidstring>, Host= mydomain.com, Request-Context= appId=<appidstring>, Request-Id= <requestidstring>