67

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.

Pang
  • 8,605
  • 144
  • 77
  • 113
lewiada
  • 1,077
  • 1
  • 9
  • 13

4 Answers4

44

**** 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.

Sam Critchley
  • 2,594
  • 1
  • 21
  • 23
  • 2
    The answer, it seems, is no - at least not with Apache 2.4. – Renee Oct 11 '16 at 21:10
  • 5
    I think that this should be the accepted answer. Works perfect for me with the comma. Basic auth and JWT. – Tadej Jan 16 '17 at 08:28
  • 1
    This seems to solve the OP's problem in the best way. – span May 09 '17 at 12:08
  • 23
    No. That section is only applicable to the header whose *entire* field value is defined as a comma-separated list, such as `Accept-Encoding` header. `Authorization` header's field value is, however, [not defined like that](https://tools.ietf.org/html/rfc7235#appendix-C). – uasi Dec 14 '17 at 10:15
  • 1
    But isn't the credentials field in the ABNF [designed to be comma-separated](https://tools.ietf.org/html/rfc7235#section-1.2) though @uasi ? – Sam Critchley Dec 14 '17 at 11:13
  • 6
    @Sam Critchley the header has one credentials field, and the credentials field consists of two parts: an auth-scheme and a param/a list of params. Params can be comma separated, but, no, the credentials field in its entirety is not a list. (Credentials being plural does not matter here — it’s a scalar value.) – uasi Dec 14 '17 at 14:14
  • 5
    This is a wrong implementation! Refer to the RFC, appendix C: https://tools.ietf.org/html/rfc7235#appendix-C Authorization is not a comma separated list. If a server accepts it, it's not implementing the protocol per the RFC. – Elie Saad Jan 29 '20 at 10:15
  • 1
    @Elie Saad, RFC 7235 says, "Note: Many clients fail to parse a challenge that contains an unknown scheme. A workaround for this problem is to list well-supported schemes (such as "basic") first." This means the header can contain multiple challenges. Each challenge is separated by commas, and each can have a comma separated list of parameters. Each parameter will have an equals sign (=) in it, while a new challenge will begin with the scheme, which doesn't have an equals sign in it. – Scott Dec 16 '20 at 03:06
  • @Scott It is a note for the `WWW-Authenticate` and `Proxy-Authenticate` headers. They can contain multiple `challenge`s, but the `Authorization` header can contain only one `scheme`. – uasi Jan 24 '21 at 03:43
  • @uasi You are correct. Thank you for the clarification. – Scott Jan 25 '21 at 16:21
33

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

Julian Reschke
  • 35,455
  • 7
  • 78
  • 83
  • 3
    Whilst I ought to believe you since I know who you are, what you say it at odds with the spec: "When creating their values, the user agent ought to do so by selecting the challenge with what it considers to be the most secure auth-scheme that it understands, obtaining credentials from the user as appropriate." — Specifically, 1) "ought", 2) token68 excludes "," meaning a comma won't be interpreted as part of a token, and 3) There's nothing in the spec to say multiple Auth. headers can't be provided i.e. 2 headers CRLF-separated. See also https://github.com/nickstenning/nginx-multiauth – Nicholas Shanks Oct 15 '15 at 12:38
  • 11
    You can only use multiple header fields when they are defined using list syntax; see http://greenbytes.de/tech/webdav/rfc7230.html#rfc.section.3.2.2.p.2 – Julian Reschke Oct 19 '15 at 08:00
  • @JulianReschke can we set a first authorization header that would contain the basic auth, and set a second authorization header that would contain the bearer auth, in the same request? – JarsOfJam-Scheduler Dec 22 '20 at 08:49
  • No, that would be invalid syntax. – Julian Reschke Dec 22 '20 at 11:09
10

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.

Community
  • 1
  • 1
Azngeek
  • 1,607
  • 2
  • 11
  • 11
-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
});
Roster
  • 1,169
  • 4
  • 12
  • 22