10
votes

Let me quote HTTP 1.1 RFC specification from www.w3.org.

10.4.2 401 Unauthorized

The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8).

14.8 Authorization

A user agent that wishes to authenticate itself with a server usually, but not necessarily, after receiving a 401 response does so by including an Authorization request-header field with the request. The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.

Why the credentials intended to prove user identity (Authentication) passed in Authorization header?

2
Because as RFC says, credentials containing the authentication information. You could use authorization to authenticate indeedLeandro Bardelli
a) it's an IETF spec,b) the current spec is RFC 7235, but yes, c) this is inconsistent.Julian Reschke

2 Answers

5
votes

You can see it like this. The server says to the client "Please authenticate before accessing this resource" and sends information on how the client should do the authentication (WWW-Authenticate). The client is responsible for authenticating and then sends proof of that authentication to the server (Authorization).

The Basic authentication scheme messes things up because the authorization is a username and password, that is, you authorize by authenticating against the server itself (showing you know a user and password).

Nevertheless other schemes allow the client to authenticate with a third-party and only send a proof of the authentication to the server. The server can verify the authorization and may not know who the client is (although it typically does).

Note This is only a rationalization. I don't mean to say this was the motive behind the chosen names.

2
votes

One possibility is that it is talking about the authorization from the user's perspective, not the server's.

There are actually two authorizations going on:

  1. The user authorizing the client to act on their behalf.
  2. The server authorizing the user to access its resources.

If we assume the header is named after 1) then we have:

The user authorized the client to act on their behalf. That authorization goes in the Authorization header. The server then used the user's authorization of the client to authenticate the user (confirm the client is acting on behalf of the user). Now it knows who the user is, it will then do its own separate checks for 2), to see if the user is authorized to perform the request.