IE11 overrides Bearer authorization header in intranet environment

Question

I'm encountering a pretty strange issue in IE11 where the browser is overriding the Authorization header in my requests even though I am setting it via AngularJS.

Basically, I have an HTTP interceptor registered for all requests that looks like this:

AuthInterceptorService.request = function (config) {
    config.headers.Authorization = "Bearer " + bearerToken;
}

This works great in all browsers (even IE under certain conditions). I have my app set up in IIS as allowing anonymous authentication and I have basic/integrated authentication disabled for this subsite, however, the parent configuration has windows authentication eabled.

What is happening occasionally is that the browser will make a request to the root URL for a static file (say, /favicon.ico). This request is denied with a 401. The browser responds with negotiated authentication and gets the favicon. At this point, all other browsers still let my code set the Authorization header, but once this integrated authentication happens in IE, the authorization header seems to get stuck - no matter what my code does, the authorization header is always using integrated authentication. This causes all requests to my API to fail because no Bearer token is present.

I was able to work around the favicon issue by specifying a more local favicon (where static files can be served anonymously), but I am wondering if there is a less hacky solution to this issue. Can I somehow convince IE to let me set the Authorization header even if Windows authentication has taken place on a previous request?

Note: I found this question which seems to be related (maybe the same underlying cause).

Answer 1

If you look at the Negotiate Operation Example of the RFC 4559 document, it involves a pseudo mechanism used by IE to negotiate the choice of security when authenticating with IIS.

The first time the client requests the document, no Authorization
header is sent, so the server responds with

       S: HTTP/1.1 401 Unauthorized
       S: WWW-Authenticate: Negotiate

The client will obtain the user credentials using the SPNEGO GSSAPI mechanism type to identify generate a GSSAPI message to be sent to
the server with a new request, including the following Authorization
header:

       C: GET dir/index.html
       C: Authorization: Negotiate a87421000492aa874209af8bc028

The server will decode the gssapi-data and pass this to the SPNEGO
GSSAPI mechanism in the gss_accept_security_context function. If the context is not complete, the server will respond with a 401 status
code with a WWW-Authenticate header containing the gssapi-data.

       S: HTTP/1.1 401 Unauthorized
       S: WWW-Authenticate: Negotiate 749efa7b23409c20b92356

The client will decode the gssapi-data, pass this into
Gss_Init_security_context, and return the new gssapi-data to the
server.

So, I don't think its possible for you to intermingle while the negotiation takes place as the process is internal