This is the ninth article in the web series, with more to come. Stay tuned! Let’s ride the waves together!
preface
Ha ha, I haven’t studied with you for a long time. Did you have a happy Spring Festival? Anyway I am lazy in the past…. I’m going to progress a little bit with you today.
There are so many resources on the network, but some resources for security, not everyone can see. In this case, the server needs the client to prove its identity. Let’s take a look at the basic HTTP authentication mechanism.
HTTP challenge/response authentication framework
HTTP provides a native challenge/response framework. Its authentication model is as follows:
- When a client initiates an HTTP request, the server does not directly fulfill the client’s request. Instead, the server responds with an authentication challenge, asking the client to provide identity information.
- When the client requests again, it must attach the information to prove its identity (user name, password, certificate, etc.) to explain its authenticity to the server.
A few things to know
Authentication protocol and header
The HTTP challenge/response framework supports two official authentication protocols: basic authentication and digest authentication. (Digest authentication will be studied together in a future article.) The HTTP header and content corresponding to the two protocols are also different. Let’s take a look at the header information used by the basic authentication protocol.
| The authentication steps | The first | describe | Method/state |
|---|---|---|---|
| request | There is no specific header when you do not know that authentication is required | GET | |
| The inquiry | WWW-Authenticate | The server returns status code 401 and rejects the request. Require a user name and password from the client. The server may be divided into different zones, and each zone requires different authentication, which is described in the WWW-Authenticate response header. The header also contains the corresponding authentication algorithm. |
401 Unauthorized |
| authorization | Authorization | The client sends a request again with an Authorization header, indicating that the user name and password have been authenticated by the algorithm. | GET |
| successful | Authentication-Info | If the authentication succeeds, the server returns the corresponding resource. Attachment information can be returned in this response header. | 200 OK |
Consider the following example:
Security domain
In the above example, the response to the challenge contains www-authenticate: Basic realm=”Family”; A server may divide documents into different domains, and a realm is the server’s identification of each domain. Different domains may require different authentication.
Base – 64 encoding
In the C request of the above example, the user name and password are base-64 encoded and sent to the server through the Authorization header. This is not a plaintext transfer. More information about base-64 can be found here. Of course, this step of conversion does not guarantee the security of the username and password.
Proxy authentication
As entities in the Web structure, proxies can also provide authentication functions for users. The schematic diagram is as follows:
| Web server header | Proxy authentication header |
|---|---|
| Unauthorized status code 401 | Unauthorized status code 407 |
| WWW-Authenticate | Proxy-Authenticate |
| Authorization | Proxy-Authorization |
| Authentication-Info | Proxy-Authentication-Info |
Problems with basic authentication
After looking at the basic authentication process, you can see some problems with it:
-
After the user name and password are transmitted over the network through base-64 encoding, a third party can capture and decode the user’s private information.
-
Even if a third party cannot directly obtain the user name and password, it can replay the intercepted data to the server to obtain the access permission of the server.
-
When a user is faced with a large number of user names and passwords, it is possible to use the same password, which leads to the risk of “collision”.
-
In short, basic certification is risky.
conclusion
This article introduces you to the basic HTTP authentication framework. In addition to basic authentication, HTTP also supports digest authentication, which we’ll continue in the next article. See you then!
note
- Some pictures come from the network, if there is infringement, please inform.
- Please point out any mistakes. ‘!
- Your liking is the greatest compliment.