I want to be a unified user authorization management center so that third-party app and websites can access the account system of this management center.
It’s a bit similar to some applications. You can register as a website member by clicking on Weibo and then log in. You don’t have to apply for an account at the website.
We provide a third-party access scheme. After the (our) user is authorized, we allow the user to log on to the third-party application. In addition, I would like to carry out more detailed management on the authority.
In order to be on the safe side, the verification of user login behavior should be done more carefully to prevent user information from being tampered with and causing losses.
In addition, the system may not use SSL
The mobile phone client opens the login webpage of the user authentication server, intercepts the returned code after login, the mobile phone client uploads the code to the back end, the back end gets access_token through the code to the authentication server, and then obtains the user information and returns it to the mobile phone client. (Reference)http://blog.csdn.net/seccloud …)
It feels safer to do this. No valuable information is exposed to the client, but every time you log in to the back end, you have to request the api twice to get the user information, which costs a lot of resources.
The mobile phone client logs in through a set of customized SDK (SDK inherits all logic of logging in to the authentication server). After successful login, the SDK will return the key user information (ID) and the unique ID generated during the session to the client as the login basis.
The client uploads the information to the back end, which then requests the authentication server. If the authentication server confirms that the user login is valid, it can be regarded as a valid session.
Operations such as logging in and pulling user information can be processed again, thus saving resources for clients that do not need additional information.
In this way, back-end verification is very simple.
The worry is that after the secret key and other user information used for authentication are intercepted by eavesdropping, the attacker logs in first, causing loss to the user.
No similar system has been done, please help me to see if there is any problem in my thinking. What are the loopholes in these schemes? Is there a more reasonable plan?
We are using 1. . . APP successfully logs in the authentication center to obtain token, APP sends token to back-end to obtain uid, etc. all subsequent requests must have uid, token, etc. …
The second is too exposed. . . The first is slightly better.