Single Sign On SSO (Single Sign On
) To put it simply, in an environment where multiple systems coexist, after users log in at one place, they do not need to Logging in in other systems means that the user's one login can be trusted by all other systems. Single sign-on is used very frequently in large websites, such as websites like Alibaba. Behind the website are hundreds or thousands of subsystems. A user's operation or transaction may involve the cooperation of dozens of subsystems. If each operation All subsystems require user authentication. Not only will the user go crazy, but each subsystem will also go crazy due to the logic of repeated authentication and authorization. In the final analysis, implementing single sign-on is to solve how to generate and store that trust, and then how other systems verify the validity of this trust. Therefore, the key points are as follows:
1. Store trust
2. Verify trust
As long as the above problems are solved and the effects mentioned at the beginning are achieved, it can be said to be SSO. The simplest way to implement SSO is to use Cookie. The implementation process is as follows:
It is not difficult to find that the above solution stores trust in the client's Cookie. This method Although it is easy to implement, people will immediately question two issues:
1. Cookies are not safe
2. Cross-domain login is not allowed
The first problem is usually solved through encrypted cookies. The second problem is a flaw. In fact, the idea of this solution is to store the trust relationship on the client. It is not possible to implement this. You must only use cookies, and you can also use flash. The Shared Object API of flash provides storage capabilities.
Generally speaking, large systems will adopt the method of storing trust relationships on the server side. The implementation process is as follows:
The above solution is to store trust relationships on the server side. The relationship is stored in a separate SSO system (let's call it that for the time being). It is simply moved from the client to the server, but several issues need to be solved:
1. How to be efficient? Store a large amount of temporary trust data
2. How to prevent the information transfer process from being tampered
3. How to make the SSO system trust the login system and Bindeng System
For the first problem, you can generally use a distributed cache solution similar to memcached, which can not only provide a mechanism for scalable data volume, but also provide efficient access. For the second question, the digital signature method is generally adopted, either through digital certificate signing or through a method like md5. This requires the SSO system to encrypt the parameters that need to be verified with md5 when returning the login URL, and bring the token. Return together. When the system that needs to be logged in finally verifies the trust relationship, the token needs to be passed to the SSO system. The SSO system can identify whether the information has been modified by verifying the token. The last problem can be solved through a whitelist. To put it simply, only systems on the whitelist can request production trust relationships. Similarly, only systems on the whitelist can be exempted from login.
For more related questions, please visit the PHP Chinese website: PHP Video Tutorial
The above is the detailed content of Detailed explanation of PHP single sign-on implementation principle examples. For more information, please follow other related articles on the PHP Chinese website!