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

Question

HTTP specification says;

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).

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

• Client sends username:password using HTTP Authorization header using HTTP Basic
• 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

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.

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?

Answer 1

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".

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?