我想知道将自定义数据放入HTTP授权标头是否可以接受。我们正在设计RESTful API，我们可能需要一种方法来指定自定义授权方法。例如，我们称之为FIRE-TOKEN身份验证。
根据规范Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=
第二个字符串的第一部分（在'：'之前）是API密钥，第二部分是查询字符串的散列。
答案 0 :(得分：129)
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语法的一些例子......
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
答案 1 :(得分：22)
将其放在单独的自定义标头中。
重载标准HTTP标头可能会导致更多的混淆，而且会违反principle of least surprise。它还可能导致API客户端程序员遇到互操作性问题，他们希望使用现成的工具包，这些工具包只能处理标准形式的典型HTTP头（例如Authorization）。
答案 2 :(得分：15)
不，根据RFC 2617中的“凭据”定义，这不是有效的制作。您提供了有效的身份验证方案，但auth-param值的格式必须为token "=" ( token | quoted-string )（请参阅第1.2节），并且您的示例不会以这种方式使用“=”。
答案 3 :(得分：9)
老问题我知道，但对于好奇：
信不信由你，这个问题在20年前用HTTP BASIC解决了，它将值传递为base64编码的用户名：密码。 （见http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side）
您也可以这样做，以便上面的示例变为：
Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==