I searched some app-specific user authentication solutions on google and compared cookie authentication in the traditional PC era. I thought it was not reasonable. I thought of a solution and I don't know if it was reasonable? This is probably the requirement. users log on to a third party and use the oauth interface to log on to our app. Large... I searched some app-specific user authentication solutions on google and compared cookie authentication in the traditional PC era. I thought it was not reasonable. I thought of a solution and I don't know if it was reasonable?
This is probably the requirement. users log on to a third party and use the oauth interface to log on to our app.
The general process is as follows:
- The user first logs on to a third party, then the client obtains the user's data and returns it to the server over https. The transmitted data is as follows:
{ “user_id”:”123123123” , “access_token”:”accesstokenstrng”, “platform”:”qq”, “platform_name”:”xxx”,}
2. After the authentication is successful on the server, you can obtain further data and create a user.
3. The server then stores user_id, logon status information, and dynamically generated secret encrypted strings in sessions and other places.
4. The server returns session_id and secret to the client and stores the secret in the memory.
5. Now, the user is successfully created and the https connection ends.
6. All subsequent requests involving backend additions, deletions, and modifications follow the http protocol. When sending data, the client first uses secret to sign the transmitted data and brings the signature and session_id together.
7. The server finds user data based on session_id and uses secret to sign the data. If the two are the same, the data is valid. Then, you can proceed to the general business logic.
Two more problems are involved:
1. Is the initial https on the client and server necessary? In fact, I can fully build the secret into the app.
2. I use secret to sign data. It seems that there is no difference between using https as a public key and private key?
Possible duplicate problems: using PHP for server interface client POST for http access security
Reply content:
I searched some app-specific user authentication solutions on google and compared cookie authentication in the traditional PC era. I thought it was not reasonable. I thought of a solution and I don't know if it was reasonable?
This is probably the requirement. users log on to a third party and use the oauth interface to log on to our app.
The general process is as follows:
- The user first logs on to a third party, then the client obtains the user's data and returns it to the server over https. The transmitted data is as follows:
{ “user_id”:”123123123” , “access_token”:”accesstokenstrng”, “platform”:”qq”, “platform_name”:”xxx”,}
2. After the authentication is successful on the server, you can obtain further data and create a user.
3. The server then stores user_id, logon status information, and dynamically generated secret encrypted strings in sessions and other places.
4. The server returns session_id and secret to the client and stores the secret in the memory.
5. Now, the user is successfully created and the https connection ends.
6. All subsequent requests involving backend additions, deletions, and modifications follow the http protocol. When sending data, the client first uses secret to sign the transmitted data and brings the signature and session_id together.
7. The server finds user data based on session_id and uses secret to sign the data. If the two are the same, the data is valid. Then, you can proceed to the general business logic.
Two more problems are involved:
1. Is the initial https on the client and server necessary? In fact, I can fully build the secret into the app.
2. I use secret to sign data. It seems that there is no difference between using https as a public key and private key?
Possible duplicate problems: using PHP for server interface client POST for http access security