Discussion on mutual authentication of API

Open APIs are a trend. And API this thing has a characteristic is spilt. Once publicly out, is used by a large number of users, once modified, will let the majority of users fall into the pit. Therefore, the API at the beginning of the design should be considered as well as possible, and set aside the expansion possible.

Most APIs are currently accessed through the HTTP protocol. APIs generally have two categories, one for the provider and the consumer, and the other for the end user. Therefore, the first category in the certification also involves only two parties, the latter category also involves user authorization, which is usually used OAuth. Let's talk about the first class here. Certifications like Amazon AWS's API, Google's map API, and so on are part of this category.

The common authentication method for both authenticated APIs is to use a set of IDs and keys, tag the app with an ID, and use the key to sign the request. The ID and key are generally applied to the service party. In this way, the service charge can also control the use of the API. If you want to stop a user from accessing the API, simply cancel the user's authentication information. Can.

For example, the API for Google Maps is simply to use a key to make a hmac_sha1 signature on the URL. Such as:

$signature = Hash_hmac ("SHA1", $url _to_sign, $key,  true);

The signature is then encoded and appended to the URL after it is accessed. The service party finds the corresponding key according to the ID in the request, and also makes the signature again, if the certificate is equal. For some more complex APIs, requests can also be passed through the HTTP header, post body. At this point, the signature needs to be signed with all the key information. In order to avoid the sensitivity of the parameter order, changing the order of the parameters only affects the signature results, and usually requires that the parameters be sorted first. Amazon AWS's new authentication protocol also changes some key parameters to one signature at a time. This is probably because SHA1 is not so reliable.

This is the simplest way to authenticate. In this way, because the key is not passed on the network, the HMAC SHA1 algorithm is irreversible, and a third party cannot impersonate another user to sign its own URL. But there's a downside to this simple approach. The same URL can be used repeatedly after the signature. Therefore, if the services or data that happen to be required by a third party are the same as yours, you can also copy your URL directly, spend your money, and read your data. This is also called replay attack.

To avoid or reduce the risk of replay attacks, some APIs take time as one of the parameters. Sign the time also to sign in together. In the service side not only to compare the signature, but also the time of the request and the service side of the time difference is within the scope of the license, such as 15 minutes. This is the case with Amazon AWS APIs. In this way, even if a request is intercepted, it will be valid within 15 minutes at most. The problem, however, is that the service cannot be invoked properly if the clock skew is large. Therefore, both the client and the server must be strictly on-time. Open ntpd on Linux, for example. In addition, there is still no good way to repeat attacks within 15 minutes. At this point, it may be possible to reduce the loss of the business. For example, for AWS, duplicate request resources will not pass because of the duplicate name, but it is often meaningless to repeatedly modify or delete resource requests. Other resource information can be replayed only within 15 minutes, and new valuable data cannot be obtained.

What if you really care about that? All of these methods are based on the condition that the protocol is not stateful. If you abandon this premise and become a stateful protocol, there is another way. For example, a one-time token can be introduced to solve. Before the first visit, request a one-time token, and then request the service's signature, and then sign the token together and pass it together. The server checks whether the token is still valid. After the request, the original token is invalidated and a new one-time token is issued. Does this look a little familiar? It's kind of like the way the session was implemented. The session is to pass a token on the client and the server to identify the status and simulate the state in the stateless Protocol. Third parties, even if they hijack a token, cannot be exploited without a key. The intercepted request is also invalidated once it is used. This effectively avoids replay attacks. However, this also comes at a cost, so that the server must maintain these sessions. may be resource intensive and may be subject to denial of service attacks. As a result, most services are not certified in this way.

The above authentication method is only suitable for the service side-the service side. And not suitable for customers, such as browsers, mobile, desktop clients and so on. Using both authentication APIs in these places will inevitably bring the app's password to the distribution. This is very dangerous. Once someone has cracked it and acquired your key, it's all over. At this point, it is also a nuisance to notify all terminals to replace the key. Typically, you need to use the app's own server as a proxy to access it. At a minimum, the signature is computed by applying its own service side. But for some services, such as cloud storage, the cost is a bit large, so that the application will still have to take a lot of traffic on their servers. To solve this problem, some API providers give another cognitive approach.

The application generates a UID for each of its own users, and then uses the key to sign the user key, Id,uid the application, and the signature is stored in the client distribution. When initiating a request from a client, take the app Id,uid and sign with the user key. The service side is verified in the same way, and the data access control can be done by UID. This way, once the client is cracked, it will only affect an end user, not the same as before, where all user information is compromised.

Reprint: http://xiezhenye.com/2013/03/api-%E5%8F%8C%E6%96%B9%E8%AE%A4%E8%AF%81%E6%8E%A2%E8%AE%A8.html

Discussion on mutual authentication of API