自定义HTTP授权头

130

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

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

第二个字符串的第一部分(冒号前面)是API密钥,第二部分是查询字符串的哈希值。

4个回答

137

RFC2617中定义的格式为credentials = auth-scheme #auth-param。因此,我同意fumanchu的看法,认为修正后的授权方案应该如下所示:

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

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

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

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

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

https://datatracker.ietf.org/doc/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提供了另一个例子。 - bishop

20
将其放在单独的自定义标头中。
过载标准HTTP标头可能会引起更多的混淆,而且会违反最小惊讶原则。这也可能会导致API客户端程序员在使用只能处理典型HTTP标头标准形式(例如授权)的现成工具包时出现互操作性问题。

3
这可能比看起来更难做好。fumanchu提供的链接(在他回答的评论中)解释了为什么引入自定义标题会增加额外的负担,因为现在必须手动正确设置Cache-Control。 - Jon-Eric
4
如果您正在通过浏览器进行跨域请求,并且使用了自定义标头,则现在已经处于预检领域,即使您本来可以避免它。对于某些应用程序来说,这些请求会累积增加。 - Wil Moore III
32
拒绝使用自定义身份验证标头。使用规范标准的Authorization标头和您自己的自定义方案应该足够。 此外,这样可以避免@wilmoore所指出的预检Origin请求。 我所知道的任何合理现代的HTTP服务器都不会干扰自定义方案,并且如果您使用自己的方案,您将不得不自己解析它-没有库应该冲突(否则该库编写不良)。 - Les Hazlewood
7
将凭据放在“Authorization”标头中传输的一个很好的原因是代理和日志记录器知道将信息视为敏感信息。 - Eron Wright

16

根据RFC 2617中“凭证”定义,这不是一个有效的生产。您提供了一个有效的认证方案,但是auth-param值必须采用token "=" ( token | quoted-string )的形式(参见第1.2节),而您的示例未以这种方式使用“=”。


1
这不正确。请参考文档第5页的示例格式:Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==。 - NRaf
12
没错。但正如http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16#section-2.3.1所述,“引入“b64token”符号是为了与现有的认证方案兼容,并且每个挑战/凭据只能使用一次。因此,新方案应该使用“auth-param”语法,否则将来的扩展将不可能。”请参见缓存讨论中关于在自定义标头中进行身份验证的内容。 - fumanchu

9

虽然这是一个老问题,但对于好奇的人:

信不信由你,大约20年前使用HTTP基础认证已经解决了这个问题,它通过Base64编码的用户名:密码传递值。 (请参见http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side)

你可以这样做,使得上面的示例变为:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==

6
我建议不采用这个答案,因为根据这里另一个回答的评论,此处使用的表示法是为了与现有方案兼容,不建议用于新扩展。 - Whymarrh

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接