HTTP protocol-based API interface for client authentication methods and security measures [go]

HTTP protocol-based API interface for client authentication methods and security measures

Since HTTP is stateless, it is normal for the browser to browse the Web, and the server will identify the client through the visitor's cookie (the jsessionid stored in the cookie). When a client logs on to the server it also stores the login information in the server and associates it with the Jsessionid in the client's cookie so that the client can access us again to identify the user.

However, for API servers, it is not safe or friendly for us to allow visitors to log in and visit first. So the general situation is that we need the client to provide a key (each key is associated with the user) to identify the requestor.

Most of the data that is communicated by the HTTP protocol is unencrypted plaintext, including request parameters, return values, cookies, head and so on, so that the outside world can easily make requests and responses, modify and steal various kinds of information according to the format of both the request and the response. So we also need to authenticate each request to determine if the user is the one who initiated the request, and whether the request information has been tampered with. Generally, the request information (request URI, parameters) is used to digest the method to solve the above problem. Because of the irreversibility of the abstract algorithm, this method can prevent the information from being tampered to a certain extent, and ensure the security of the communication.

1, MD5 Way

Users need to first apply for key, secret on the site, and then the verification process is as follows:

Client :

1. Parameter Ordering

2. String the arguments together with secret to generate the text to be summarized

3. Generate a digest string using a digest algorithm such as MD5 signature

4. Put key,signature into the header and pass it to the server
Server :

1. Parameter Ordering

2. String the arguments together with secret (obtained through the key in the header in the database) to generate the

3. Generate a digest string using a digest algorithm such as MD5

4. The summary string generated by the server is compared with the summary string that the client passed through the header.

2, HmacSHA256 Way

Users need to first apply for key, secret on the site, and then the verification process is as follows:

Customer List :

1. Encapsulate the request parameter as a JSON string, which is the request body body

2. Use the HMACSHA256 algorithm plus secret to generate a digest of (request Url+nonce+body) encryption signature

3. Put key,signature into the header and pass it to the server

Server :

1. Get the request body body string in the request

2. Use the HMACSHA256 algorithm plus secret (get through the key in the header in the database) to generate a digest (Request Url+nonce+body) encryption signature

3. The summary string generated by the server is compared with the summary string that the client passed through the header.

Note that using HmacSHA256 is more secure, and we can encapsulate the request parameters directly into a JSON string into the request body (that is, through the IO stream) for delivery.

Problems encountered in actual use:

1. The underlined header is filtered

When we use HmacSHA256 for authentication, we need the client to put the request key,signature into Header,name set to Api_key,api_signature, then there is a problem is how the server can not get these two values, But I have no problem with this machine test. Later only to think of is not because of the use of Nginx to do the cluster and some of the head is filtered, after the view is sure to be nginx will have the underlined header name filter, and then modify the Nginx configuration can be normal to obtain the header information. But then the server used a third-party dynamic acceleration again to filter the underlined header name, in order to avoid trouble simply modify the program to remove the underscore in header name.

2. Ensure uniqueness of each request

Since HTTP is a clear-text request, although we can make sure that the information is not tampered with through a summary of security assurances, we cannot guarantee the uniqueness of each request, that is, if the request data is requested by someone else, it can also pose a serious security issue. So we need the user to set an incremental parameter nonce in each request to ensure that each request is unique. However, this can also lead to a problem, that is, if the user almost simultaneously initiates two requests a B, because the network is blocked, may be initiated after the first B to reach the server, so when a is reached, the server will consider a nonce has expired request illegal and refused. To solve this problem we allow the user to set a expire value to avoid the problem of nonce authentication.

3. SNI

Because we have different projects (different domain names, with different certificates) on the same server, so that some client access to our API project will throw an exception, said the HTTP handshake failed or the request domain name and the server certificate does not match the failure. So we need the client program to support SNI, which allows the client to submit the host information of the request when initiating the SSL handshake request (specifically, the ClientHello phase of the client issuing the SSL request), allowing the server to switch to the correct domain and return the corresponding certificate. For the Java language, the subsequent version of Jdk7 already supports SNI, or it can be well supported with HttpClient 4.3 and later versions.

HTTP protocol-based API interface for client authentication methods and security measures [go]