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.

回答1:

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.

回答2:

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

回答3:

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.