自定义授权HTTP标头


81

当客户端向API发送请求时,我需要对客户端进行身份验证。客户端具有API令牌,我正在考虑使用标准Authorization标头将令牌发送到服务器。

通常,此标头用于BasicDigest身份验证。但是我不知道是否允许自定义此标头的值并使用自定义的身份验证方案,例如:

Authorization: Token 1af538baa9045a84c0e889f672baf83ff24

你会推荐吗?还是有更好的发送令牌的方法?

Answers:


51

您可以创建使用Authorization:标头的自己的自定义身份验证架构-例如,这就是OAuth的工作方式。

通常,如果服务器或代理不了解标准标头的,则它们将不理会标头。它正在创建自己的标头,这些标头通常会产生意想不到的结果-许多代理会使用不认识的名称来剥离标头。

话虽如此,使用cookie传输令牌而不是Authorization:标题是一个更好的主意,原因很简单,因为cookie被明确设计为承载自定义值,而HTTP内置的auth方法的规范并未真正说明无论哪种方式-如果您想确切了解其含义,请在此处查看

与此有关的另一点是,许多HTTP客户端库都内置了对Digest和Basic auth的支持,但是当尝试在标头字段中设置原始值时可能会使工作变得更加困难,而它们都将提供对cookie的轻松支持,并且在其中允许或多或少的任何价值。


9
很高兴得知OAuth是如何工作的。我不确定使用cookie是否会使客户端实现更简单。除非您的客户端是浏览器,否则在客户端中实现cookie的规则(路径,到期时间等)要比记住设置标题字段复杂得多。大多数客户端库使设置正确的标头变得相当简单。
Thomas Watson

2
@ThomasWatson虽然我无法同意您在Cookie范围方面的意见,但这在这里并不重要。HTTP身份验证的范围(使用Authorization:标头)是每个域的。这意味着,如果将Cookie的域设置为“此域”,并将路径设置为“ /”,则其作用域与HTTP auth的作用域相同。但是,这实际上取决于您-但正如Julian Reschke所指出的那样,除非您决定否则您不应该定义新的身份验证方案feel that you have something of generic use-可以在其他应用程序中使用的方案。
DaveRandom 2011年

8

如果是CROSS ORIGIN请求,请阅读以下内容:

我遇到了这种情况,起初我选择使用AuthorizationHeader,然后在遇到以下问题后将其删除。

Authorization标头被视为自定义标头。因此,如果使用AutorizationHeader设置进行跨域请求,则浏览器将首先发送预检请求。预检请求是通过OPTIONS方法发出的HTTP请求,此请求从请求中剥离所有参数。您的服务器需要使用Access-Control-Allow-Headers具有您的自定义标头(Authorization标头)的值的标头进行响应。

因此,对于客户端(浏览器)发送的每个请求,浏览器都会发送一个附加的HTTP请求(OPTIONS)。这降低了我的API的性能。您应该检查是否添加此选项会降低性能。作为一种解决方法,我在http参数中发送令牌,我知道这不是最好的方法,但是我不能牺牲性能。


我也在考虑仅在http参数中发送我的sessionID。为什么说这不是最好的方法?看起来它具有针对防火墙剥离标头的健壮性以及针对跨源性能降低的优势。它的缺点是什么?
thund

1
缺点仅在GET请求的情况下。我必须Authorization token对我的应用程序使用我的(敏感数据)对用户进行身份验证。出于同样的原因,我们不应该在GET中发送敏感数据,也不应该在params中使用授权令牌。按照w3 w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3 “ HTTP协议不应使用基于GET的形式提交敏感数据”。
Abhishek Kumar

如果您不喜欢标题,则可以将令牌存储在cookie中。(不要将令牌与会话ID混淆)。请注意,通过PUT和DELETE,它将始终发送选项。...请注意,大多数情况下,您使用服务器端REST客户端,而浏览器并不被认为是非常好的REST客户端。
inf3rno

5

这有点过时,但可能还有其他人在寻找相同问题的答案。您应该考虑哪些保护空间对您的API有意义。例如,您可能希望标识和验证客户端应用程序对API的访问权限,以将其限制用于已知的注册客户端应用程序。在这种情况下,您可以使用Basic客户端身份作为用户ID,客户端共享密钥作为密码的身份验证方案。您不需要专有的身份验证方案,只需清楚地标识客户端将为每个保护空间使用的方案即可。我希望每个保护空间都只使用一个,但是HTTP标准允许在每个WWW-Authenticate标头响应中使用多个身份验证方案,并且在每个响应中都允许多个WWW-Authenticate标头。这会使API客户端混淆使用哪些选项。保持一致和清晰,然后将使用您的API。


2

我建议不要对自定义方案名称使用HTTP身份验证。但是,如果您觉得自己有通用的用途,则可以定义一个新方案。有关详细信息,请参见http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-latest.html#rfc.section.2.3


链接到的文档是HTTP / 1.1的草案。我一直在尝试查看最终标准,但找不到任何关于必须注册自定义方案的信息。难道不只是在起草过程中,他们想要找到并同意默认方案吗?
Thomas Watson

托马斯,我引用的文档是RFC 2616/7的修订版(没有针对方案的注册表)。它正在进行中,但即将完成。
朱利安·雷施克

0

请尝试以下邮递员:-

在标题部分的示例为我工作。

授权:JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9。eyIkX18iOnsic3RyaWN0TW9kZSI6dHJ1ZSwiZ2V0dGVycyI6e30sIndhc1BvcHVsYXRlZCI6ZmFsc2UsImFjdGl2ZVBhdGhzIjp7InBhdGhzIjp7InBhc3N3b3JkIjoiaW5pdCIsImVtYWlsIjoiaW5pdCIsIl9fdiI6ImluaXQiLCJfaWQiOiJpbml0In0sInN0YXRlcyI6eyJpZ25vcmUiOnt9LCJkZWZhdWx0Ijp7fSwiaW5pdCI6eyJfX3YiOnRydWUsInBhc3N3b3JkIjp0cnVlLCJlbWFpbCI6dHJ1ZSwiX2lkIjp0cnVlfSwibW9kaWZ5Ijp7fSwicmVxdWlyZSI6e319LCJzdGF0ZU5hbWVzIjpbInJlcXVpcmUiLCJtb2RpZnkiLCJpbml0IiwiZGVmYXVsdCIsImlnbm9yZSJdfSwiZW1pdHRlciI6eyJkb21haW4iOm51bGwsIl9ldmVudHMiOnt9LCJfZXZlbnRzQ291bnQiOjAsIl9tYXhMaXN0ZW5lcnMiOjB9fSwiaXNOZXciOmZhbHNlLCJfZG9jIjp7Il9fdiI6MCwicGFzc3dvcmQiOiIkMmEkMTAkdTAybWNnWHFjWVQvdE41MlkzZ2l3dVROd3ZMWW9ZTlFXejlUcThyaDIwR09IMlhHY3haZWUiLCJlbWFpbCI6Im1hZGFuLmRhbGUxQGdtYWlsLmNvbSIsIl9pZCI6IjU5MjEzYzYyYWM2ODZlMGMyNzI2MjgzMiJ9LCJfcHJlcyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbbnVsbCxudWxsLG51bGxdLCIkX19vcmlnaW5hbF92YWxpZGF0ZSI6W251bGxdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltudWxsXX0sIl9wb3N0cyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbXSwiJF9fb3JpZ2luYWxfdmFsaWRhdGUiOltdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltdfSwiaWF0IjoxNDk1MzUwNzA5LCJleHAiOjE0OTUzNjA3ODl9.BkyB0LjKB4FIsCtnM5FcpcBLvKed_j7rCCxZddwiYnU


1
您是否真的在JWT中发送密码/哈希?这是一个简单的base64。
扎哈尔

1
@Zakhar:SPA的非常典型的做法是将整个用户会话封装在JWT中(因为它是一个完整的json文档),从而消除了在服务器端存储会话的需要。
Cowbert

@cowbert:我不确定在JWT中封装某些内容是否比某些会话令牌更典型(请参见本帖子)。
亚历山大·阿巴库莫夫

@AlexanderAbakumov那篇文章充满误导,他得到了一些要点,但是他的许多要点是没有道理的,其中有些他只是毫无根据地反对,我可以说他只是喜欢饼干,我认为他需要从中获取一些东西。面包店整理他的文章,我遇到了很多情况,我使用cookie并浪费了几天的工作,带有localStorage的JWT节省了我很多头疼和时间,这只是2个小时的工作和繁琐的工作,再也不需要访问它了。我想知道他是否曾经开发过移动应用程序,尝试过严格限制安全规则的浏览器等等。
Al-Mothafar '19

@ Al-Mothafar:如果您以某种方式扩展您的语句(例如)等that article full of misleadings,我将不胜感激a lot of his points does not make sense(意味着,这里可能超出了评论的范围)。也许您可以写答案或博客文章?比较参数真的很有趣。
亚历山大·阿巴库莫夫
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.