自定义HTTP授权标头


124

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

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

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

Answers:


133

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

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

FIRE-TOKEN方案在哪里,两个键值对是auth参数。尽管我相信引号是可选的(摘自p7-auth-19的附录B)...

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

我相信这符合最新标准,已经在使用中(请参阅下文),并且提供了用于简单扩展的键值格式(如果需要其他参数)。

可以在此处查看此auth-param语法的一些示例...

http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-4.4

https://developers.google.com/youtube/2.0/developers_guide_protocol_clientlogin

https://developers.google.com/accounts/docs/AuthSub#WorkingAuthSub


4
亚马逊的简单存储API提供了另一个示例。
主教

18

将其放在单独的自定义标题中。

重载标准的HTTP标头可能会造成比其应有的更多的混乱,并且会违反“ 最少惊喜”原则。如果您的API客户端程序员希望使用仅能处理典型HTTP标头(例如Authorization)的标准格式的现成工具包,也可能会导致互操作性问题。


3
这可能很难正确解决。fumanchu提供的链接(在对他的回答的评论中)解释了为什么引入自定义标头会增加额外的负担,即现在必须手动正确设置Cache-Control。
Jon-Eric

4
另外,如果您正在通过浏览器发出跨域请求,则由于自定义标头的原因,您现在处于预检区域,否则可以避免该标头。对于某些应用程序,这些请求加起来。
维尔摩尔三世

31
自定义身份验证标头的数量巨大。Authorization具有您自己的自定义方案的spec-standard 标头应该绰绰有余。另外,您避免使用@wilmoore指示的飞行前Origin请求。自定义方案不会干扰我所知道的任何合理的现代HTTP服务器,此外,如果您使用自己的方案,则必须自己解析它-库不应该发生冲突(否则库编写得不好)。
Les Hazlewood

7
Authorization标头(而不是自定义标头)中传输凭据的一个很好的理由是,代理和记录器知道将信息视为敏感信息。
伊隆·赖特

15

不,根据RFC 2617中的“凭据”定义,这不是有效的产品。您提供了有效的auth-scheme,但是auth-param值必须采用以下格式token "=" ( token | quoted-string )(请参见1.2节),并且您的示例不使用“ =”。


1
那是不对的。有关示例格式,请参阅文档的第5页:授权:基本QWxhZGRpbjpvcGVuIHNlc2FtZQ ==
NRaf 2011年

11
确实如此。但是正如tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16#section-2.3.1所述,“ b64token”表示法是为了与现有身份验证方案兼容而引入的,每次只能使用一次因此,新方案应该改为使用“ auth-param”语法,因为否则将来的扩展将是不可能的。” 另请参阅有关在自定义标头中执行身份验证的缓存讨论。
fumanchu

9

我知道一个老问题,但出于好奇:

信不信由你,这个问题在大约20年前用HTTP BASIC解决了,该问题将值传递为base64编码的username:password。(请参阅http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side

您可以执行相同的操作,因此上面的示例将变为:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==

4
我建议不要使用此答案,因为在此对另一个答案进行评论时,此处使用的符号是为了与现有方案兼容,不建议用于新扩展。
Whymarrh
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.