多个HTTP授权标头？

Question

多个HTTP授权标头？

是否可以在HTTP消息中包含多个授权标头？具体来说,我想包括一个承载令牌类型(传递OAuth访问令牌)和一个基本类型(传递base64编码的用户名:密码).

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

Run Code Online (Sandbox Code Playgroud)

我认为没有理由这是不可能的,只是想与社区一起审查以确定.

Answer 1

Sam*_*ley 38

这应该是可能的,您只需在字段值之间添加逗号,例如:

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

Run Code Online (Sandbox Code Playgroud)

这在RFC7230,第3.2.2节,字段顺序中定义:

发件人不得在邮件中生成具有相同字段名称的多个标题字段,除非该标题字段的整个字段值定义为逗号分隔列表[即#(值)]或标题字段是否为已知异常(如下所述).

收件人可以将具有相同字段名称的多个头字段组合成一个"field-name:field-value"对,而不改变消息的语义,方法是将每个后续字段值按顺序附加到组合字段值,由a分隔逗号.因此,接收具有相同字段名称的头字段的顺序对于组合字段值的解释是重要的; 代理不得在转发消息时更改这些字段值的顺序.

我不知道是否所有网络服务器都接受了这一点 - 在撰写本文时,我正在与同事讨论是否应该工作.

不可以.该部分仅适用于其*整个*字段值定义为逗号分隔列表的标头,例如`Accept-Encoding`标头.但是,"授权"标题的字段值是[未定义的](https://tools.ietf.org/html/rfc7235#appendix-C). (14认同)
我认为这应该是公认的答案.用逗号来完善我的作品.基本身份验证和JWT. (5认同)
@Sam Critchley标题有一个凭证字段,凭证字段由两部分组成:auth-scheme和param/params列表.Params可以用逗号分隔,但是,不,整个凭证字段不是列表.(凭证是复数并不重要 - 它是标量值.) (5认同)
这是一个错误的实现！请参阅 RFC，附录 C：https://tools.ietf.org/html/rfc7235#appendix-C 授权不是逗号分隔列表。如果服务器接受它，则它不会按照 RFC 实现该协议。 (5认同)
答案似乎是否定的-至少在Apache 2.4中不是。 (2认同)
@Scott这是“WWW-Authenticate”和“Proxy-Authenticate”标头的注释。它们可以包含多个“challenge”，但“Authorization”标头只能包含一个“scheme”。 (2认同)

Answer 2

Jul*_*hke 20

不,这是不可能的.请参阅http://greenbytes.de/tech/webdav/rfc7235.html#header.authorization中的语法定义

使用list语法定义时,只能使用多个头字段; 见http://greenbytes.de/tech/webdav/rfc7230.html#rfc.section.3.2.2.p.2 (7认同)
虽然我应该相信你，因为我知道你是谁，你所说的与规范不一致：“在创造他们的价值时，用户代理应该通过选择它认为是最安全的身份验证的挑战来做到这一点。 - 它理解的方案，根据需要从用户那里获取凭据。” — 具体来说，1）“应该”，2）token68 排除“”，这意味着逗号不会被解释为令牌的一部分，以及 3）规范中没有任何内容可以说明多重身份验证。无法提供标头，即 2 个标头 CRLF 分隔。另见 https://github.com/nickstenning/nginx-multiauth (3认同)

Answer 3

Azn*_*eek 10

我有一个类似的问题.这似乎是一个非常普遍的问题(链接问题).我最终将承载令牌的授权标题更改为非标准的标题

X-Auth:承载mF_9.B5f-4.1JqM

这样它只是另一个HTTP头,基本的http授权将通过.如果您正在开发自己的API,这应该没问题.

一些进一步的研究

基于RFC 2617,这里有一些有趣的细节.

用户代理必须选择使用其理解的最强auth方案中的一个挑战,并基于该挑战从用户请求凭证.

请注意,许多浏览器只会识别Basic,并且要求它是第一个提供的身份验证方案.服务器应该只包括Basic,如果它是最低限度可接受的.

RFC 2617现在无关紧要.您需要检查RFC 7235. (5认同)

归档时间：	10 年，5 月前
查看次数：	24639 次
最近记录：	6 年，3 月前