How to ensure API interface security?

In the actual business development process, we often encounter the need for technical docking with third-party Internet companies, such as Alipay payment docking, WeChat payment docking, Amap query docking and other services. If you It is an entrepreneurial Internet, and most of it may be connected to the API interfaces of other companies.

When your company grows in size, some companies may start looking for you for technical docking, and you will provide the API interface. At this time, how should we design and ensure What about API interface security?

There are two main types of most commonly used solutions:

Among them, the token solution is the most widely used interface authentication solution on the web. I remember writing one before. The article "Teaching you step by step, using JWT to implement single sign-on" is more detailed. Friends who are interested can take a look. It doesn't matter if you don't understand it. We will briefly introduce the token solution here.

From the above figure, we can clearly see that the implementation of the token solution mainly includes the following steps:

In actual use, when the user logs in successfully, the The token is time-limited when stored in redis. It is generally set to 2 hours. It will automatically expire after 2 hours. At this time, we need to log in again and obtain a valid token again.

The token solution is currently the most widely used solution among business-type projects, and it is very practical and can effectively prevent hackers from capturing packets and crawling data.

But the token solution also has some disadvantages! The most obvious one is when connecting with a third-party company. When your interface request volume is very large, the token suddenly becomes invalid, and a large number of interface requests will fail.

I have a deep understanding of this. I remember that very early on, when I was doing joint debugging with a medium or large Internet company, the interface docking solution they provided me was the token solution. At that time, our company During peak traffic periods, a large number of errors are reported on the interfaces requesting them. The reason is that the token has expired. When the token expires, we will call them to refresh the token interface. After the refresh is completed, during the time interval between the token expiration and the token re-refresh, there will be There are a large number of logs of failed requests, so in the actual API docking process, I do not recommend you to use the token solution.

Interface signature, as the name suggests, is to sign parameters through some signature rules, and then put the signed information into the request header. After the server receives the client request, it only needs to follow the predetermined The signature string corresponding to the rule production is compared with the client's signature information. If they are consistent, the business processing process will be entered; if not, a signature verification failure will be prompted.

In the interface signature scheme, there are mainly four core parameters:

The signature generation rules are divided into two steps:

Parameter 2 encryption result, This is the final signature string we want.

The interface signature scheme is still very stable, especially when the interface request volume is large.

In other words, you can think of interface signatures as a complement to the token scheme.

But if you want to extend the interface signature scheme to front-end and back-end docking, the answer is: not suitable.

Because the signature calculation is very complicated, and secondly, it is easy to leak the appsecret!

Having said so much, let’s practice it with the program!

As mentioned above, the key point of the token solution is that after the user successfully logs in, we only need to generate the corresponding token and then return it to the front end. The next time the business interface is requested, we need Bring the token.

Specific practices can also be divided into two types:

Below, we introduce the second implementation method.

First, write a jwt tool.

Next, when we log in, we generate a token and return it to the client.

Finally, write a unified interceptor to verify whether the token passed in by the client is valid.

When generating a token, we can store some basic user information, such as user ID and user name, into the token. In this way, after the token authentication is passed, we only need to parse the information inside. , you can obtain the corresponding user ID, which saves the operation of querying some basic information in the database.

At the same time, try not to store sensitive information during use, because it can easily be parsed by hackers!

With the same idea, from the perspective of server-side verification, we can first write a signature interceptor to verify whether the parameters passed in by the client are legal. As long as one of the parameters is illegal, an error will be prompted.

The specific code practice is as follows:

Signature tool class SignUtil:

For signature calculation, you can switch to hamc method for calculation, the idea is roughly the same.

The token and interface signature scheme introduced above can protect the provided interface externally, preventing others from tampering with requests or simulating requests.

However, there is a lack of security protection for the data itself, that is, the requested parameters and returned data may be intercepted and obtained by others, and these data are in clear text, so as long as they are intercepted, they can be obtained. Corresponding business data.

In this case, it is recommended that you encrypt the request parameters and return parameters, such as RSA, AES and other encryption tools.

At the same time, in the production environment, using https for transmission can play a very good role in security protection!