What are the simple and effective authentication user methods for public and private mixed APIs?

Existing a resetful API, is used for mobile phone app, most of the content is not required to login to browse, but also a part of the registered user login to use, there is no way to verify the user after the login authenticity, want to return a Access_token (custom , non-OAuth method), but still feel the risk of risking it. Do you have any way to verify the authenticity of this user instead of stealing Access_token impersonation?

Reply content:

Existing a resetful API, is used for mobile phone app, most of the content is not required to login to browse, but also a part of the registered user login to use, there is no way to verify the user after the login authenticity, want to return a Access_token (custom , non-OAuth method), but still feel the risk of risking it. Do you have any way to verify the authenticity of this user instead of stealing Access_token impersonation?

This is a typical 如何证明我是我的问题 , non-secure approach that can only increase security by increasing the difficulty. There are a lot of ways, the token you call is one of the common methods, the simplest and most effective is to use HTTPS encrypted transmission. Others, such as important operations, require a password, a dynamic password, and so on each time.

The above is a technical approach, and there is a security approach that is non-technical and more of a sociological category (and certainly ultimately through technical means). such as the feature library. Each user has a set of features to identify, and as the number of uses increases, the collection of this feature becomes more detailed, and the system can then use these features to verify whether the consumer is himself. such as the user's common login, mobile device characteristics, input habits, habits, hobbies and so on. These are like a person's fingerprints, which are hard to forge. But this thing is not so easy to realize.

Security is like this, spear and shield relationship, there is no invincible spear, there is no absolute defense of the shield. Everything has to be compromised, as long as the cost of cracking more than the benefits of the break, you can think the system is safe.

Resetful is stateless, there is a possibility that there will be a risk of being used.

Tokens are generated using the same set of encryption methods as the client.
Token is not lawful and is rejected outright.
Verification through, according to the information inside, such as a user id=1, the server decrypted to determine whether id=1 users can log in.
If the client is deserialized, the algorithm is known that the user is still logged on only if the logon information is on the server.
Theoretically, if every token is different, there is no possibility of being caught, and that is meaningless.

The private API can use token to authenticate the user, control the user's request frequency, and avoid API misuse.

