Multiple HTTP Authorization headers?

Is it possible to include multiple Authorization Headers in an HTTP message? Specifically, I would like to include one of Bearer token type (passing an OAuth access token) and one of Basic type (passing a base64 encoded username:password).

GET /presence/alice HTTP/1.1 
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM
Authorization: Basic YXNkZnNhZGZzYWRmOlZLdDVOMVhk

I see no reason this should not be possible, just wanted to vet it with the community to be sure.

**** UPDATE Feb 2021 *** Please read the comments to this response. Their general conclusion seems to be that some web servers accept multiple Authorization schemes, but that it goes against RFC 7230/7235 ****

This should be possible, you just have to add a comma between field values, e.g:

GET /presence/alice HTTP/1.1 
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM, Basic YXNkZnNhZGZzYWRmOlZLdDVOMVhk

This is defined in RFC7230, section 3.2.2, Field Order:

> A sender MUST NOT generate multiple header fields with the same field name in a message unless either the entire field value for that header field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below). > > A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by a comma. The order in which header fields with the same field name are received is therefore significant to the interpretation of the combined field value; a proxy MUST NOT change the order of these field values when forwarding a message.

I don't know whether all web servers accept this - at the time of writing I'm in the middle of a debate with a colleague about whether it should work or not.

No, it's not possible. See the syntax definition in <http://greenbytes.de/tech/webdav/rfc7235.html#header.authorization>

I had a similar question. It seems to be a quite common issue (Link to question). I ended up with changing the authorization header for the bearer token to a non standard one like

> X-Auth:Bearer mF_9.B5f-4.1JqM

This way it is just another HTTP header and the basic http authorization will pass. If you are developing your own API this should be no problem.

Some further research

Based on the RFC 2617 here are some interesting details.

> The user agent MUST choose to use one of the challenges with the strongest auth-scheme it understands and request credentials from the user based upon that challenge.

> Note that many browsers will only recognize Basic and will require that it be the first auth-scheme presented. Servers should only include Basic if it is minimally acceptable.

If you are using python in backend then you can simply pass dict in bearer and before processing it in backend do json.loads

This way you can pass multiple values in one authorisation header

Example: Pass {"access_token" : access_token, "app_id" : 2}

backend json.loads("{"access_token" : access_token, "app_id" : 2}")

Header fields are key/value pairs. So as long as they are unique and you/programmers know who is who, this is fine

AuthorizationBearer: Bearer mF_9.B5f-4.1JqM
AuthorizationBasic: Basic YXNkZnNhZGZzYWRmOlZLdDVOMVhk

My Angular interceptor sends Authorization111: Bearer xyz123 to Node API, API extracts the token as

var token = header.headers["authorization111"].toString().split(' ')[1];

It is Possible to have mulitple Authorization Headers, I have gone through the same problem during integrating API which is accepting multiple authorizations.

Here is React js example for calling an API which is accepting multiple auth tokens.

axios.get(Constants.API+Constants.GET_USER,  {  headers: {
'Accept': 'application/json',
'Content-Type': 'application/json',
"Authorization": Constants.AUTH_Element + ',' + Constants.AUTH_ORG + ','+ 
Constants.AUTH_USER
}})
.then(function (response) {
    // handle success
    console.log(response);
})
.catch(function (error) {
    // handle error
    console.log(error);
})
.finally(function () {
    // always executed
});