自定义授权 HTTP 标头
当客户端向 API 发送请求时，我需要对客户端进行身份验证。客户端有一个 API 令牌，我正在考虑使用标准 Authorization 标头将令牌发送到服务器。
通常此标头用于Basic 和Digest 身份验证。但我不知道是否允许我自定义此标头的值并使用自定义身份验证方案，例如：
Authorization: Token 1af538baa9045a84c0e889f672baf83ff24
您会推荐这个吗？或者有更好的方法来发送令牌吗？
I need to authenticate a client when he sends a request to an API. The client has an API-token and I was thinking about using the standard Authorization header for sending the token to the server.
Normally this header is used for Basic and Digest authentication. But I don't know if I'm allowed to customize the value of this header and use a custom authentication scheme, e.g:
Authorization: Token 1af538baa9045a84c0e889f672baf83ff24
Would you recommend this or not? Or is there a better approach for sending the token?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您可以使用
Authorization:标头创建自己的自定义身份验证架构 - 例如，这就是 OAuth< /a> 有效。作为一般规则，如果服务器或代理不理解标准标头的值，它们将不理会它们并忽略它们。它正在创建您自己的标头键，这通常会产生意想不到的结果 - 许多代理会删除带有它们无法识别的名称的标头。
话虽如此，使用 cookie 来传输令牌可能是一个更好的主意，而不是使用
Authorization:标头，原因很简单，cookie 被明确设计为携带自定义值，而HTTP 内置的身份验证方法并没有真正说明任何一种方式 - 如果您想确切地了解它的含义，看看这里。关于这一点的另一点是，许多 HTTP 客户端库都内置了对 Digest 和 Basic auth 的支持，但在尝试在标头字段中设置原始值时可能会让生活变得更加困难，而它们都将为 cookie 提供简单的支持，并且将或多或少地允许其中存在任何价值。
You can create your own custom auth schemas that use the
Authorization:header - for example, this is how OAuth works.As a general rule, if servers or proxies don't understand the values of standard headers, they will leave them alone and ignore them. It is creating your own header keys that can often produce unexpected results - many proxies will strip headers with names they don't recognise.
Having said that, it is possibly a better idea to use cookies to transmit the token, rather than the
Authorization:header, for the simple reason that cookies were explicitly designed to carry custom values, whereas the specification for HTTP's built in auth methods does not really say either way - if you want to see exactly what it does say, have a look here.The other point about this is that many HTTP client libraries have built-in support for Digest and Basic auth but may make life more difficult when trying to set a raw value in the header field, whereas they will all provide easy support for cookies and will allow more or less any value within them.
对于CROSS ORIGIN请求，请阅读以下内容：
我遇到了这种情况，起初我选择使用
Authorization标头，后来在遇到以下问题后将其删除。Authorization标头被视为自定义标头。因此，如果使用Autorization标头设置发出跨域请求，浏览器首先会发送预检请求。预检请求是通过 OPTIONS 方法发出的 HTTP 请求，该请求会从请求中删除所有参数。您的服务器需要使用具有自定义标头（Authorization标头）值的Access-Control-Allow-Headers标头进行响应。因此，对于客户端（浏览器）发送的每个请求，浏览器都会发送一个额外的 HTTP 请求（OPTIONS）。这降低了我的 API 的性能。
您应该检查添加此内容是否会降低您的性能。作为一种解决方法，我在 http 参数中发送令牌，我知道这不是最好的方法，但我不能牺牲性能。
In the case of CROSS ORIGIN request read this:
I faced this situation and at first I chose to use the
AuthorizationHeader and later removed it after facing the following issue.AuthorizationHeader is considered a custom header. So if a cross-domain request is made with theAutorizationHeader set, the browser first sends a preflight request. A preflight request is an HTTP request by the OPTIONS method, this request strips all the parameters from the request. Your server needs to respond withAccess-Control-Allow-HeadersHeader having the value of your custom header (Authorizationheader).So for each request the client (browser) sends, an additional HTTP request(OPTIONS) was being sent by the browser. This deteriorated the performance of my API.
You should check if adding this degrades your performance. As a workaround I am sending tokens in http parameters, which I know is not the best way of doing it but I couldn't compromise with the performance.
这有点过时了，但可能还有其他人在寻找同一问题的答案。您应该考虑哪些保护空间对您的 API 有意义。例如，您可能想要识别和验证客户端应用程序对 API 的访问，以将其使用限制为已知的、已注册的客户端应用程序。在这种情况下，您可以使用
Basic身份验证方案，其中客户端标识符作为用户 ID，客户端共享密钥作为密码。您不需要专有的身份验证方案，只需明确标识客户端为每个保护空间使用的身份验证方案即可。我更喜欢每个保护空间只使用一个，但 HTTP 标准允许在每个 WWW-Authenticate 标头响应上使用多个身份验证方案，并且在每个响应中允许使用多个 WWW-Authenticate 标头；这会让 API 客户端感到困惑要使用哪些选项。保持一致和清晰，您的 API 才会被使用。This is a bit dated but there may be others looking for answers to the same question. You should think about what protection spaces make sense for your APIs. For example, you may want to identify and authenticate client application access to your APIs to restrict their use to known, registered client applications. In this case, you can use the
Basicauthentication scheme with the client identifier as the user-id and client shared secret as the password. You don't need proprietary authentication schemes just clearly identify the one(s) to be used by clients for each protection space. I prefer only one for each protection space but the HTTP standards allow both multiple authentication schemes on each WWW-Authenticate header response and multiple WWW-Authenticate headers in each response; this will be confusing for API clients which options to use. Be consistent and clear then your APIs will be used.我建议不要将 HTTP 身份验证与自定义方案名称一起使用。如果您觉得自己有一些通用的东西，您可以定义一个新的方案。请参阅http://greenbytes。有关详细信息，请参见/tech/webdav/draft-ietf-httpbis-p7-auth-latest.html#rfc.section.2.3。
I would recommend not to use HTTP authentication with custom scheme names. If you feel that you have something of generic use, you can define a new scheme, though. See http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-latest.html#rfc.section.2.3 for details.
请在邮递员上尝试以下内容：-
在标题部分示例中为我工作..
授权：JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9..BkyB0LjKB4FIsCtnM5FcpcBLvKed_j7rCCxZddwiYnU
Kindly try below on postman :-
In header section example work for me..
Authorization : JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyIkX18iOnsic3RyaWN0TW9kZSI6dHJ1ZSwiZ2V0dGVycyI6e30sIndhc1BvcHVsYXRlZCI6ZmFsc2UsImFjdGl2ZVBhdGhzIjp7InBhdGhzIjp7InBhc3N3b3JkIjoiaW5pdCIsImVtYWlsIjoiaW5pdCIsIl9fdiI6ImluaXQiLCJfaWQiOiJpbml0In0sInN0YXRlcyI6eyJpZ25vcmUiOnt9LCJkZWZhdWx0Ijp7fSwiaW5pdCI6eyJfX3YiOnRydWUsInBhc3N3b3JkIjp0cnVlLCJlbWFpbCI6dHJ1ZSwiX2lkIjp0cnVlfSwibW9kaWZ5Ijp7fSwicmVxdWlyZSI6e319LCJzdGF0ZU5hbWVzIjpbInJlcXVpcmUiLCJtb2RpZnkiLCJpbml0IiwiZGVmYXVsdCIsImlnbm9yZSJdfSwiZW1pdHRlciI6eyJkb21haW4iOm51bGwsIl9ldmVudHMiOnt9LCJfZXZlbnRzQ291bnQiOjAsIl9tYXhMaXN0ZW5lcnMiOjB9fSwiaXNOZXciOmZhbHNlLCJfZG9jIjp7Il9fdiI6MCwicGFzc3dvcmQiOiIkMmEkMTAkdTAybWNnWHFjWVQvdE41MlkzZ2l3dVROd3ZMWW9ZTlFXejlUcThyaDIwR09IMlhHY3haZWUiLCJlbWFpbCI6Im1hZGFuLmRhbGUxQGdtYWlsLmNvbSIsIl9pZCI6IjU5MjEzYzYyYWM2ODZlMGMyNzI2MjgzMiJ9LCJfcHJlcyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbbnVsbCxudWxsLG51bGxdLCIkX19vcmlnaW5hbF92YWxpZGF0ZSI6W251bGxdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltudWxsXX0sIl9wb3N0cyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbXSwiJF9fb3JpZ2luYWxfdmFsaWRhdGUiOltdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltdfSwiaWF0IjoxNDk1MzUwNzA5LCJleHAiOjE0OTUzNjA3ODl9.BkyB0LjKB4FIsCtnM5FcpcBLvKed_j7rCCxZddwiYnU