Authentication mechanism for HTTP

The computer itself is unable to determine the identity of the user, which requires the user "tell", usually need to check the information has these:

① Password: Only I will know the string information.

② Dynamic Tokens: Only one-time passwords displayed within the device I hold.

③ Digital Certificate: Only the information held by me (terminal).

④ Biometric authentication: Fingerprint and iris and other physiological information.

⑤ic Card, etc.: limited to the information I hold.

The authentication methods used by http/1.1 have these:

①BASIC Certification (Basic certification).

②digest Certification (Digest certification).

③SSL Client authentication.

④formbase certification (based on form authentication).

⑤windows Unified Certification ("Illustrated HTTP" is not explained in the first, again not to introduce it)
　　

　　Basic Certification

Basic authentication is the authentication method defined from http/1.0, which is the authentication method between Web server and communication client.

Step ① When the requested resource requires Basic authentication, the server returns a response with the Www-authenticate header field with the status code of 401Authorization Required. This field contains the authentication method (BASIC) and the Request-uri security domain string.

Step ② receive the status Code 401 client in order to pass Basic authentication, the user ID and password need to be sent to the server. The string content that is sent is composed of a user ID and a password, which is concatenated with a colon (:), then Base64 encoded.

Step ③ accepts the server containing the Header field authorization request and verifies the correctness of the authentication information. If validation passes, a response containing the Request-uri resource is returned.

Although Basic authentication is BASE64 encoded, this is not a cryptographic process. No additional information is needed to decode it, so it is easy for others to steal information, and, in order to do a basic certification, the General browser is unable to achieve the authentication logoff operation.

As a result, digest certification was born.

　　Digest Certification

Digest authentication also uses a challenge/response approach, but does not send plaintext passwords directly like Basic authentication.

The so-called question response means that the first party will send the authentication request to the other party, and then use the question received from the other party to calculate the generated response code. Finally, the response code is returned to the other party to authenticate the way. Because the knowledge response summary sent to each other and the result of the calculation generated by the challenge code, the probability of password leakage is reduced compared to the basic authentication.

Step ① when requesting a resource for authentication, the server returns a response with the Www-authenticate header field along with the status Code 401. This field contains the temporary challenge code required to interrogate the response mode authentication. The first field in the Www-authenticate must contain information about both realm and nonce fields. The client relies on authenticating the two values to the server. A nonce is any random string that is generated each time a 401 response is returned. This string is usually recommended as a form of hexadecimal number encoded by Base64, but the actual content depends on the specific implementation of the server.

Step ② The client receiving the 401 status code, the returned response contains the Digest authentication must be the Header field authorization information. The field information for username, realm, nonce, URI, and response must be included in the header field authorization. Where realm and nonce are the fields in the response previously received from the server.

Step ③ receives the server containing the Header field authorization request and confirms the correctness of the authentication information. After the authentication is passed, the response containing the Request-uri resource is returned. And then write some information about the success of the authentication in the header field Authentication-info. Digest certification provides a higher level of security than basic authentication, but is still weak compared to HTTPS client authentication. Digest authentication provides protection against password eavesdropping, but there is no protection mechanism to protect users from spoofing.

　　SSL Client Authentication

SSL client authentication is the way that authentication is done by the client certificate of HTTPS. With client certificate authentication, the server can confirm that access is from a logged-on client.

To achieve SSL client authentication, the client certificate needs to be distributed to the client in advance, and the client must install the certificate. Is the authentication step for SSL client authentication:

Step ① receives a request for authentication resources, the server Hi sends a certificate request message requesting the client to provide a client certificate.

Step ② After the user chooses the client certificate that will be sent, the client sends the client certificate information to the server in Certificate message mode.

Step ③ server verifies that client certificate validation passes before you can claim the public key of the client in the certificate, and then begins HTTPS encrypted communication.

Moreover, the general SSL client authentication and the form authentication combination form a two-factor authentication to use. That is, the SSL client certificate for the first authentication factor is used to authenticate the client computer, and the password for another authentication factor is used to determine the user's behavior. With two-factor authentication, you can confirm that the user is using the correct computer to access the server.

Form-based authentication

In most cases, after entering the login information such as user ID and password, we send it to the Web application and decide whether the authentication is successful based on the result of authentication. The standard specification for forms-based authentication has not yet been finalized, and a cookie is generally used to manage the session.

Based on the form authentication itself is through the server side of the Web application, the client sent over the user ID and password to match the previously logged information to do the authentication. But the balance HTTP is a stateless protocol, so we use cookies to manage the session to compensate for state management functions that do not exist in the HTTP protocol.

　

Step ① The client puts the login information such as user ID and password into the entity part of the message, usually sends the request to the server by the Post method. At this point, HTTPS communication is used for the display of HTML form screen and the sending of user 怓 data.

Step ② The server will issue the session ID used to identify the user. The login information sent by the client is authenticated, then the authentication status of the user is bound to the SessionID and recorded on the server side. When a response is returned to the client, the session ID is written to the header field Set-cookie.

Step ③ After the client receives the session ID sent from the server side, it will be stored as a cookie locally, and the next time the request is sent to the server, the browser will automatically send the cookie, so the session ID is sent to the server. The server can identify the user and its authentication status by verifying the received session ID.

Authentication mechanism for HTTP