请求中的HTTP授权标头一致性

时间:2022-08-22 19:39:28

HTTP specification says;

HTTP规范说;

HTTP access authentication is described in "HTTP Authentication: Basic and Digest Access Authentication" [43]. If a request is authenticated and a realm specified, the same credentials SHOULD be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks).

HTTP访问认证在“HTTP认证:基本和摘要访问认证”[43]中描述。如果请求被认证并且指定了域,则相同的凭证应该对该域内的所有其他请求有效(假设认证方案本身不需要,例如根据挑战值或使用同步时钟而变化的凭证) 。

I don't really understand what this means, but here is my scenario is there anything against HTTP specs here? I use Java Rest service

我真的不明白这意味着什么,但是我的情况是这里有什么反对HTTP规范的吗?我使用Java Rest服务

  • Client sends username:password using HTTP Authorization header using HTTP Basic
  • 客户端使用HTTP Basic使用HTTP Authorization标头发送用户名:密码

  • Server sends back a token
  • 服务器发回一个令牌

  • Now client sends a custom authorization token instead of password for further requests still in the HTTP authorization header still using HTTP Basic username:token
  • 现在,客户端仍然使用HTTP Basic username:token为HTTP授权标头中的其他请求发送自定义授权令牌而不是密码

Now this does not feel right since what I am really doing with the auth token is NOT an actual HTTP Basic authorization. Also usage of the very same header is inconsistent between requests.

现在这感觉不对,因为我真正使用auth令牌做的不是实际的HTTP基本授权。在请求之间使用相同的头也是不一致的。

But on the other hand I do not want create yet another custom header for the token exchange. Because its hard to base64 encode them with test tools when you use a custom header. And still inconsistent headers between requests.

但另一方面,我不想为令牌交换创建另一个自定义标头。因为当您使用自定义标头时,难以使用测试工具对其进行编码。请求之间仍然存在不一致的标头。

Note: these requests refers to different endpoints

注意:这些请求指的是不同的端点

What do you advice?

你有什么建议?

1 个解决方案

#1


0  

If you do that, since you are using the same headers, aren't you going to need server side logic to differentiate when the login is the actual login, as opposed to your token? At the end of the day, HTTP Authorization is already a token (only a simple encoded version of the username/password string), so in all cases you are receiving a token, now you have to decode it, decide if it's one of your session tokens, or if it's a username/password, and therefore check against two sources of "good tokens".

如果你这样做,既然你使用相同的标题,那么当登录是实际登录时,你是不是需要服务器端逻辑来区分你的令牌?在一天结束时,HTTP授权已经是一个令牌(只是用户名/密码字符串的简单编码版本),所以在所有情况下你都收到一个令牌,现在你必须解码它,决定它是否是你的一个会话令牌,或者如果它是用户名/密码,因此检查两个“好令牌”来源。

I would advice against this, but not because you're breaking standards, it just feels convoluted.

我会建议不要这样做,但不是因为你打破了标准,只是感觉很复杂。

Why do you need to change username/password to a token on the first place? Are you redirecting to an endpoint where you no longer require HTTP Basic Auth?

为什么你需要在第一个地方更改用户名/密码到令牌?您是否重定向到不再需要HTTP Basic Auth的端点?

#1


0  

If you do that, since you are using the same headers, aren't you going to need server side logic to differentiate when the login is the actual login, as opposed to your token? At the end of the day, HTTP Authorization is already a token (only a simple encoded version of the username/password string), so in all cases you are receiving a token, now you have to decode it, decide if it's one of your session tokens, or if it's a username/password, and therefore check against two sources of "good tokens".

如果你这样做,既然你使用相同的标题,那么当登录是实际登录时,你是不是需要服务器端逻辑来区分你的令牌?在一天结束时,HTTP授权已经是一个令牌(只是用户名/密码字符串的简单编码版本),所以在所有情况下你都收到一个令牌,现在你必须解码它,决定它是否是你的一个会话令牌,或者如果它是用户名/密码,因此检查两个“好令牌”来源。

I would advice against this, but not because you're breaking standards, it just feels convoluted.

我会建议不要这样做,但不是因为你打破了标准,只是感觉很复杂。

Why do you need to change username/password to a token on the first place? Are you redirecting to an endpoint where you no longer require HTTP Basic Auth?

为什么你需要在第一个地方更改用户名/密码到令牌?您是否重定向到不再需要HTTP Basic Auth的端点?