Small knowledge, big challenge! This article is participating in the creation activity of “Essential Tips for Programmers”

This article has participated in the “Digitalstar Project” and won a creative gift package to challenge the creative incentive money.

In our daily development, we often connect to some third-party SDKapi, and the connection to these SDKS will inevitably encounter the problem of parameter signature authentication. In the following two articles, I will explain what is interface parameter signature authentication and how OpenFeign implements interface parameter signature authentication. So let’s get started

Why do interfaces use parameter signatures

For those of you who have not yet been exposed to parameter signature verification, we will take a closer look at what happens and why 😍 is needed.

When we use the third-party SDK, we generally do not need to log in to obtain authentication information. Why? If login is used, the process is tedious and it is difficult to maintain authentication information. So we can see that the general three-party open sdkapi provides us with an appkey (some are called appid, but it’s the same thing) and an appsecret instead of logging in. Some partners will have a question, this and parameter signature verification has what relationship? 🤪 Don’t panic. We’ll take our time.

So first of all, let’s think about, how do we implement interface authentication with just appKey and AppSecret? You can close your eyes and think about it. Will appKey and AppSecret be passed as parameters? 🤓, hee hee, there should be no students think so…

Just to be clear, appKey indicates who you are, appSecret indicates who you really are, and appKey and AppSecret are two values that must be included in the request information. In order for someone to find you, appKey must be given to them directly. Appsecret needs to use some kind of “encrypted” way to hide in the parameter, during authentication, check whether the identity information matches, match ok, match wrong, then goodbye. What’s missing is some kind of encryption. Not to be kept in suspense, let’s get straight to how this quoted “encryption” usually works.

  1. General three-party open SDKAPI will require at least three parameters, appkey, sign, timestamp, these three parameters, may have their own names, first of all, the first appkey, some three-party SDK called appID, this is nothing to talk about, this is used to indicate identity. Then the third parameter timestamp (here is only a name, the generation refers to the necessary parameters except appkey, sign), this is a bit more tedious, maybe each three party SDK name is different, common, It can be timestamp, nonce, salt, rand, etc. It can also be a combination of several parameters. Its main function is to generate the second parameter sign as an inclusion parameter, and we will talk about the second parameter sign.

  2. Sign is generally generated by hash algorithm, and the original string is generally assembled by appKey + Appsecret + request parameter or request body + TIMESTAMP (this stitching rule is equivalent to the “encryption” method mentioned in the previous paragraph). After our common hash algorithm MD5 or SHA-1 processing, we get our final sign. When we receive the parameter at the back end, we will obtain the appsecret of the corresponding user through appkey. If we do not find appSecret, we will definitely fail the authentication directly. Then we will splice each parameter according to the agreed “encryption” method. Then use the same hash algorithm to generate a sign, and finally compare with the parameter sign on the parameter. If the parameter is consistent, the authentication passes. Another point to note here is that the request parameters or request body must be ordered to ensure that the interface document declaration is consistent, so as to ensure that the request parameters or request body received by the backend is consistent, so that the generated sign will not have unexpected errors.

  3. Some of you might have this question, right? The third timestamp parameter in the previous paragraph is not useful, if this parameter is removed, the back end must run equally well. This is a good idea, a clever boy, but there is a problem. If the requested address is caught by someone else, someone else can constantly access the requested address to obtain the resource. The result of the verification on the back end is always passed, so the third parameter timestamp is necessary.

  4. For different SDKAPI providers, each of them has different implementation methods and security strength. If the security strength is low, the third parameter timestamp may only need a unique random value nonce, and the backend only needs to judge whether this nonce has been used, if it has been used, it will be judged not to pass. This ensures that each request is unique. While some have high security intensity, the third parameter timestamp may consist of two or more parameters. The third parameter timestamp consists of a timestamp timestamp and a random value of the nonce. The backend verifies whether the nonce has been used and how much the time difference between the timestamp and the server is. If the difference is greater than a certain value, it will also be rejected. For example, if the value of the backend is set to 5 seconds, the timestamp of each request cannot exceed 5 seconds compared with the server time. Requests with an interval of more than 5 seconds will be considered as replay attacks or incorrect requests, which greatly ensures the security of the interface. Knowing this principle, the third parameter timestamp has N possible combinations.

With some back-end thinking, for me, who has been doing back-end dishes for several years, among N combinations of the third parameter timestamp, the one with the timestamp must be better. If we want to ensure the uniqueness of the request, then we need a place to store the third parameter timestamp that has been requested. If you have a lot of requests and a lot of time, maintaining this thing is definitely going to get nerve-racking. And with the timestamp, there is an expiration time, if more than the set value, directly throw away can reduce maintenance and storage costs 😜

To summarize

Let’s summarize what the above three parameters do

  1. Ensure that each request is unique
  2. Prevent parameter tampering
  3. Ensure that the request is valid and comes from an authenticated user

This is why we need parameter signature verification 😵

This is the end of this article, due to the lack of time, the second part of OpenFeign how to implement interface parameter signature authentication will continue tomorrow at 👻, thanks for your support and encouragement.

If the article is helpful to you, welcome to like, comment, pay attention to, collect, share, your support is my code word power, thank you!! 🌈

If the content of the article is wrong, welcome to correct, exchange, thank 😘

Finally, you can click here to join the QQ group FlutterCandies🍭 and communicate with various gurus

Refer to the link

  • OpenFeign