我想知道在HTTP授权头中放置自定义数据是否可接受。我们正在设计RESTful API,可能需要指定一种自定义的授权方法。例如,我们称之为FIRE-TOKEN
身份验证。
像这样的东西是否有效和允许根据规范:Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=
第二个字符串的第一部分(冒号前面)是API密钥,第二部分是查询字符串的哈希值。
我想知道在HTTP授权头中放置自定义数据是否可接受。我们正在设计RESTful API,可能需要指定一种自定义的授权方法。例如,我们称之为FIRE-TOKEN
身份验证。
像这样的东西是否有效和允许根据规范:Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=
第二个字符串的第一部分(冒号前面)是API密钥,第二部分是查询字符串的哈希值。
在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
授权
)的现成工具包时出现互操作性问题。Authorization
标头和您自己的自定义方案应该足够。 此外,这样可以避免@wilmoore所指出的预检Origin请求。 我所知道的任何合理现代的HTTP服务器都不会干扰自定义方案,并且如果您使用自己的方案,您将不得不自己解析它-没有库应该冲突(否则该库编写不良)。 - Les Hazlewood根据RFC 2617中“凭证”定义,这不是一个有效的生产。您提供了一个有效的认证方案,但是auth-param值必须采用token "=" ( token | quoted-string )
的形式(参见第1.2节),而您的示例未以这种方式使用“=”。
虽然这是一个老问题,但对于好奇的人:
信不信由你,大约20年前使用HTTP基础认证已经解决了这个问题,它通过Base64编码的用户名:密码传递值。 (请参见http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side)
你可以这样做,使得上面的示例变为:
Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==