自定义 HTTP 授权头

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

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

第二个字符串的第一部分(在“ :”之前)是 API 键,第二部分是查询字符串的散列。

153737 次浏览

将其放在一个单独的自定义标头中。

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

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

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

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 语法的一些示例..。

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

我知道这是个老问题了,不过好奇的人可以问:

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

你也可以这样做,这样上面的例子就会变成:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==