How to Implement restful web API Authentication

Recently, I want to use a small project to test restful Web APIs. There are only a few calls in the project, which is relatively simple, but also requires authentication. If it is a traditional website, I don't need to say that, it must be that the user name + password get the logon token on the logon page, and the logon token is recorded in the cookie and session as the identity, but now it is different, the key is restful, this means that the APIS we designed are stateless. The next call request should be completely unrelated to this call request, that is, the authentic restful web API should contain complete information every time it is called, including identity information!

So how to ensure security? What is MD5 encryption for the password during transmission? Come on! This can only make you feel "safe". In fact, it is useless. You can use the current technology (what is rainbow table? I am a layman, not very familiar with it) I will soon be able to calculate the plaintext password, and how can I prevent hijacking and re-attack?

You may have thought of SSL. If you plan to adopt SSL, please forget all the self-designed encryption solutions, because SSL has already helped you do everything, including preventing listening and holding, prevent resending ...... Everything helps you think about it. You can write the plaintext password in your package and it will be OK. I promise you no problem.

However, the disadvantage of SSL is that the configuration on the server is a little complicated. The more important thing is that the client may not support this. So you should consider your own encryption method? Here I provide a method from the following. (The legendary plagiarism? The method is described as follows:

1. Assume there is a user named guogangj and the password is 123456 (er ...... Can this also be called a password ?)
2. He wants get http://test.com/api/orders/
3. So I just want to explain it)
4. The username guogangj and xxxxooxxxxoooo are included in the data packet and sent to the server.
5. After receiving the package, the server finds the password 123456 in the database based on the user name guogangj.
6. The server uses the password "123456" to decrypt the ciphertext "xxxxooxxxxoooo". The plaintext is obtained: http://test.com/api/orders/this Urland The GUID generated by the customer.
7. The server searches for the guid in a global collection to see if it already exists. If it exists, the verification fails. If it does not exist, it is placed in the collection. This is to avoid repeated attacks. This global set will become larger and larger, so it needs to be cleaned regularly.
8. The server checks whether the decrypted URL is consistent with the URL actually requested by the user. If the URL is consistent, the server considers it a legal user and passes verification!

This is a general process. If the user cannot be found in the database or the decryption is incorrect, the authentication fails. The following are some improvements:

1. It is best to make a summary of the password in the database (such as MD5), and the client also needs to do it.
2. When generating ciphertext, you can consider adding other sensitive content that you do not want to transmit in plain text, or even adding IP addresses for verification on the server.
3. Not every time you actually need to get user information from the database, maybe you have a better way, such as a simple cache (but you need to handle the cache update problem ), or when your system reaches a certain level, you may consider using a unified service to obtain user information. This is not as simple as caching.ArticleMany, I believe that today's large-scale portal websites all have their own complex mechanisms, so it shows that restful Web APIs are "inefficient ", however, such restful ideas and models have great plasticity and power in practice.

This method should be safe enough!

The password is not transmitted over the network at all. The ciphertext uses non-authenticated symmetric encryption and cannot be reversed without a key, URL authentication avoids traditional identity hijacking attacks (that is, intercepting a user's package and impersonating this user to access other resources, even if the user's password cannot be cracked ), using guid to avoid repeated attacks, the only concern is that the user has disclosed his or her password.

Yuan Fang, what do you think?