How to do single-user app login in PHP

The current requirement is for an app to be used for communication tools such as QQ. Single user login. Logins from other places are blocked. Previous logins. I don’t know how to implement it. Has anyone done this?

Reply content:

The current requirement is for an app to be used for communication tools such as QQ. Single user login. Logins from other places are blocked. Previous logins. I don’t know how to implement it. Has anyone done this?

Collect the device information where the app is located, and bind the device information to the user. One user is allowed to use it on one device, and the user of the previous device is kicked out when logging in.

In the past six months, we have designed and implemented a single sign-on system (TnSSO). This is a very common system, but we have done a lot of in-depth and detailed research on functions and experience. Here is a summary and record. In the following, SSO also refers to this system.

TnSSO provides multiple login methods for the PC version and the mobile version. There are regular email accounts or mobile phone numbers to log in, joint login using Sina, QQ and other accounts, and mobile phone dynamic password login. In addition, it also targets different platforms. Each company also provides some special login methods to improve user experience. For example, when you open the company's shared link in WeChat, you can log in directly using WeChat authorization, while on the PC page, you can scan the QR code to log in.

Many of the current mobile App pages directly embed ordinary mobile web pages into the App. The App acts as a browser. Needless to say, there are advantages to this. Because the App native page login experience is better than opening a web page in the App and then logging in, we still use the native page login in the App. TnSSO is compatible with the App's native login method and can identify the login status of users in the App. In addition, you can also use the App to scan the QR code to log in to the PC version of SSO.

The following is a sequence diagram of single sign-on. The details will not be explained. Those who have not been exposed to it before should be able to understand what is going on by looking at the picture:

Security and Experience
TnSSO has some very detailed considerations in terms of security and experience. On the premise of ensuring system security, the program optimizes the user experience to the maximum extent.
1. The entire process is HTTPS to prevent the communication between the client and the server from being eavesdropped.
2. Set the callback URL and whitelist. The client subsystem must first register with SSO to access SSO.
3. The token is valid once and is bound to the client subsystem, and is destroyed immediately after use.
4. In order to improve the user experience, users are not required to enter a verification code for the first three logins per IP per day, or the first dynamic password sent per mobile phone number per day.
5. A verification code will become invalid after being sent to the mobile phone dynamic password more than 3 times.
6. Wait...

Compatible with App login
App user login information is stored separately in the App and does not use the public login service provided by SSO. So when a user accesses an embedded webpage through an App, how does the webpage know the user's login status, and how can the embedded webpage and App login status be shared?

Our solution is that when the App accesses the embedded page PageA that requires login, PageA will 302 jump to the SSO login page. This process is all performed in the App, and the App is accessing the SSO login page. A hash value will be added to the cookie. After SSO receives the request, it first determines whether SSO itself is in the logged-in state. If not, it uses the hash value in the cookie to request the user ID from the App server. After obtaining the user ID, it generates user login information, and then brings the token to jump to the system where PageA is located. WebA's callback URL, WebA can log in by repeating the above login process. If the hash value is empty or the user ID retrieved from the App server based on the hash value is empty, jump to a URL used to be hijacked by the App, and repeat the above process after the App completes the login.

The App sets a hash value in the cookie instead of setting the user ID directly for security reasons. Only the user ID retrieved from the App server through SSO's own interface adjustment can ensure legitimacy and be trustworthy.
The timing diagram is as follows:

Scan QR code to log in
Scan QR code to log in is a very popular practice now. Users have been logged in on their mobile phones or other mobile devices, and this is trustworthy. Use it to provide PC version login A shortcut, simple and fast, with a good experience. Users no longer need to enter long and complicated passwords that may not be remembered by the users themselves. Therefore, this login method is also what we must provide. Although it has not been officially released yet, it has already been planned and designed.
The specific implementation method is that the SSO server first randomly generates a non-conflicting code and stores it in the database, and draws it into a QR code image to display on the PC version login page. The page uses Javascript short polling to send the code to the server. Query the corresponding login information of this code. The App uses the built-in code scanning function to identify the code in the picture, and then requests the SSO interface through the App server using the code and the hash value of the user login information mentioned above as parameters. After receiving the request, SSO first determines whether the code exists in our database. If it exists, it means the request is legitimate, and then requests the App server to obtain the user ID using the hash value. The subsequent process is almost the same as the above mentioned connection with App login. JS polls to see that the user is logged in and then refreshes the page, or jumps back to where it came from.

Finally, TnSSO not only provides unified login services, but also integrates user registration, password retrieval and other functions, so it is more appropriate to call it a pass system. It is the system with the highest requirements for stability and security in the company.

http://atlantisplus.net/articles/570.html

Looking at the many things done upstairs, it seems to be copied. Successful login records the timestamp and sets a cookie based on the timestamp. When logging in, the cookie is parsed and compared with the timestamp. In fact, just get a token, and update this token every time you log in successfully

One is like the one mentioned above that binds the uid and the device. Each operation detects whether the uid matches the current device.
There is also a third party like Huanxin that provides a single sign-on function and callback processing. , no need to make long links yourself