When your company grows in size, at this time, some companies may start looking for you to do technical docking, and you will provide api interfaces. How to design and ensure the security of API interface at this time?
There are two main types of schemes most commonly used:
Among them, token scheme is the most widely used interface authentication scheme on the web. I remember writing an article "Teach you how to use JWT to achieve single sign-on", which has a detailed introduction. Interested friends can have a look. It doesn't matter if you don't understand. Here is a brief introduction to the token scheme.
From the above figure, we can clearly see that the implementation of the token scheme mainly includes the following steps:
In the actual use process, when the user logs in successfully, the generated token is stored in redis for a limited time, which is generally set to 2 hours, and will automatically expire after 2 hours. At this time, you need to log in again and get a valid token again.
Token scheme is the most widely used scheme in business types at present, which is very practical and can effectively prevent hackers from grabbing packages and data.
But the token scheme also has some disadvantages! The most obvious thing is that when you interface with a third-party company, when your interface request is very large, the token suddenly fails at this time, and a large number of interface requests will fail.
I have a deep understanding of this. I remember a long time ago, when I was debugging with a medium and large Internet company, the interface docking scheme they provided me was token scheme. At that time, at the peak of our company's traffic, I let their interfaces report a lot of errors. Because the token failed. When tokens fail, we will call them to refresh the token interface. After the refresh is completed, there will be a large number of failed requests during the time interval from token invalidation to token refresh, so I don't recommend you to adopt token scheme in the actual API docking process.
Interface signature, as the name implies, is to sign the parameters through some signature rules, and then put the signature information into the request header. After receiving the request from the client, the server only needs to generate the corresponding signature string according to the set rules and compare it with the signature information of the client. If they are consistent, enter the business processing flow. If it fails, you will be prompted that the signature verification failed.
In the interface signature scheme, there are mainly four core parameters:
Among them, the signature generation rule is divided into two steps:
The encryption result of parameter 2 is the final signature string we want.
Interface signature scheme, especially in the case of a large number of interface requests, is still very stable.
In other words, you can think of the interface signature as a supplement to the token scheme.
But if you want to extend the interface signature scheme to front-end docking, the answer is: no.
Because the signature calculation is very complicated, and secondly, it is easy to reveal appsecret!
Having said that, let's practice with the program!
As mentioned above, the key point of the token scheme is that when the user logs in successfully, we only need to generate the corresponding token and return it to the front end, and we need to bring the token with us when we request the business interface next time.
Specific practices can also be divided into two types:
Next, we introduce the second implementation.
First, write a jwt tool.
Then, 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 in the token, such as user ID and user name, so that after the token is authenticated, we only need to analyze the information inside to get the corresponding user ID, which can save the operation of querying some basic information in the database.
At the same time, during use, try not to store sensitive information, because it is easy to be analyzed by hackers!
Similarly, from the perspective of server verification, we can first write a signature interceptor to verify whether the parameters passed in by the client are legal. As long as one item is illegal, we will prompt an error.
Specific coding practices are as follows:
Signature tool class signature:
Signature calculation can be changed to hamc method, and the idea is basically the same.
The above token and interface signature scheme can protect the provided interface to prevent others from tampering with the request or simulating the request.
However, there is a lack of security protection for the data itself, that is, the requested parameters and returned data may be intercepted by others, and these data are plaintext, so as long as they are intercepted, the corresponding business data can be obtained.
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!