自定义HTTP授权标头

Question

我想知道将自定义数据放入HTTP授权标头是否可以接受.我们正在设计RESTful API,我们可能需要一种方法来指定自定义授权方法.举个例子,我们称之为FIRE-TOKEN身份验证.

根据规范,这样的事情是否有效并允许: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

第二个字符串的第一部分(在':'之前)是API密钥,第二部分是查询字符串的哈希.

Answer 1

RFC2617中定义的格式是credentials = auth-scheme #auth-param.因此,在同意fumanchu时,我认为更正的授权方案看起来像

Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="

FIRE-TOKEN方案在哪里,两个键值对是auth参数.虽然我相信引号是可选的(来自p7-auth-19的Apendix B)......

auth-param = token BWS "=" BWS ( token / quoted-string )

我相信这符合最新标准,已经在使用(见下文),并为简单扩展提供了键值格式(如果您需要其他参数).

这里可以看到这个auth-param语法的一些例子......

[亚马逊的简单存储API](http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html)提供了另一个例子. (4认同)

Answer 2

将它放在一个单独的自定义标题中.

重载标准的HTTP标头可能会导致更多的混乱,并且会违反最少惊喜的原则.它还可能导致API客户端程序员的互操作性问题,他们希望使用现成的工具包,这些工具包只能处理标准形式的典型HTTP头(例如Authorization).

巨大的自定义身份验证标头.具有您自己的自定义方案的规范标准`Authorization`标头应该绰绰有余.另外,如@wilmoore所示,您可以避免飞行前的Origin请求.自定义方案不会干扰我所知道的任何合理的现代HTTP服务器,如果你使用自己的方案,你必须自己解析它 - 没有库应该冲突(否则库写得很差). (28认同)
在"Authorization"标头中而不是在自定义标头中传输凭证的一个很好的理由是代理和记录器知道将信息视为敏感信息. (6认同)
此外,如果您通过浏览器发出跨域请求,那么您现在处于飞行前的区域,因为您可以避免使用自定义标头.对于某些应用程序,这些请求会相加. (4认同)
这可能比看上去更难.fumanchu提供的链接(在对他的回答的评论中)解释了为什么引入自定义标头会增加现在必须正确手动设置Cache-Control的额外负担. (3认同)

Answer 3

不,根据RFC 2617中的"凭证"定义,这不是有效的生产.您提供了有效的身份验证方案,但auth-param值必须是格式token "=" ( token | quoted-string )(请参阅第1.2节),并且您的示例不使用"=".

确实如此.但是,正如http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16#section-2.3.1所说,""b64token"符号是为了与现有的身份验证方案兼容而引入的,并且只能每个挑战/凭证使用一次.新的方案因此应该使用"auth-param"语法,因为否则未来的扩展是不可能的." 另请参阅有关在自定义标头中执行身份验证的缓存讨论. (11认同)

Answer 4

老问题我知道,但对于好奇:

信不信由你,这个问题在20年前用HTTP BASIC解决了,它将值传递为base64编码的用户名:密码.(见http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side)

您也可以这样做,以便上面的示例变为:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==

我建议不要使用此答案，因为[在此处对另一个答案进行评论]（/sf/ask/546148151/#comment9522460_7809486），此处使用的表示法是为了与现有方案，不建议用于新扩展。 (4认同)