An in-depth analysis of the method of implementing SSO single sign-on in PHP

SSO means that in multiple application systems, users only need to log in once to access all mutually trusted application systems. So how to implement SSO single sign-on in PHP? The following article will give you a detailed introduction to the implementation of single sign-on SSO.

SSO (Single Sign On), that is, single sign-on, is a kind of access permission that controls multiple related but independent systems. Users with this permission can Use a single ID and password to access one or more systems to avoid using different usernames or passwords, or configure a configuration to log in to each system seamlessly.

For large systems, using single sign-on can reduce a lot of trouble for users. Take Baidu as an example. There are many subsystems under Baidu - Baidu Experience, Baidu Knows, Baidu Library, etc. If we use these systems, each system requires us to enter a user name and password to log in once. I I believe the user experience will definitely plummet.

There are two elements that interact with SSO: 1. User, 2. System. Its characteristics are: One login, all access. SSO is a type of access control, which controls whether users can log in, that is, verifies the user's identity, and all other system authentication is performed here. Looking at SSO from the entire system level, its core is these three elements. : 1. User, 2. System, 3. Authentication center.

1. How to perform single sign-on for the same domain but different subdomains

If our site is as follows The domain name is deployed:

• sub1.onmpw.com
• sub2.onmpw.com

Both sites share the same domain onmpw.com.

By default, the browser will send the host corresponding to the domain to which the cookie belongs. In other words, the default domain for cookies from sub1.onmpw.com is .sub1.onmpw.com. Therefore, sub2.onmpw.com will not get any cookie information belonging to sub1.onmpw.com. Because they are on different hosts, and their subdomains are also different.

1.1 Set the cookie information of both under the same domain

• Log in to the sub1.onmpw.com system
• After successful login, Generate a unique identifier Token (if you know the token, you will know which user is logged in). Set cookie information. It should be noted here that the Token is stored in the cookie, but when setting, the domain to which this cookie belongs must be set to the top-level domain .onmpw.com. The setcookie function can be used here. The fourth parameter of this function is used to set the domain of the cookie.

setcookie(‘token’, ’xxx’, '/', ’.onmpw.com’);复制代码

• When you visit the sub2.onmpw.com system, the browser will send the information token in the cookie to the sub2.onmpw.com system along with the request. At this time, the system will first check whether the session is logged in. If not logged in, it will verify the token in the cookie to achieve automatic login.

• sub2.onmpw.com Write session information after successful login. For future verification, just use your own session information to verify it.

1.2 Log out

There is a problem here that after the sub1 system logs out, in addition to clearing its own session information and the domain it belongs to .onmpw .com cookie information. It does not clear the session information of the sub2 system. That sub2 is still logged in. In other words, although this method can achieve single sign-on, it cannot achieve simultaneous logout. The reason is that although sub1 and sub2 can share cookies through the setting of the setcookie function, their sessionIds are different, and this sessionId is also stored in the form of a cookie in the browser, but the domain it belongs to is not .onmpw. com.

So how to solve this problem? We know that in this case, as long as the sessionId of the two systems is the same, this problem can be solved. In other words, the domain to which the cookie storing sessionId belongs is also .onmpw.com. In PHP, sessionId is generated after session_start() is called. If you want sub1 and sub2 to have the same sessionId, you must set the domain to which the sessionId belongs before session_start():

ini_set('session.cookie_path', '/');
ini_set('session.cookie_domain', '.onmpw.com');
ini_set('session.cookie_lifetime', '0');复制代码

• #1. Through the above steps, you can achieve different second-level domain names Single sign-on and sign-out.
• 2. However, it can be simplified further. For example, by ensuring that sessionId is the same, single sign-on and logout of different second-level domain names can be achieved.
• Reference article: https://www.onmpw.com/tm/xwzj/network_145.html

##2. How to implement single link between different domains Single sign-on - CAS

Suppose we need to implement single sign-on between the following stations

www.onmpw1.com
• www.onmpw2. com
• www.onmpw3.com

The above solution will not work.

Currently there is an open source SSO solution on github. The implementation principle is similar to that of mainstream SSO: https://github.com/jasny/sso

Core principle:

• 1, The client accesses different subsystems, and the SSO user service center corresponding to the subsystem uses the same SessionId.
• 2, Subsystem Broker and Server are bound to the authorization link through attach

If the same root domain name does not specify the domain root domain name, the first authorization is required You have to jump to the authorization service every time, but if you specify a domain, as long as one of the same root domain names is authorized successfully, they can share that cookie. You don't need to authorize it next time, and you can directly request user information.

First visit to A:

Second visit to B:

2.1 Login status judgment

After the user logs in to the authentication center, a session is established between the user and the authentication center. We call this session Global Session. When the user subsequently accesses the system application, it is impossible for us to go to the authentication center to determine whether to log in every application request. This is very inefficient, and this is something that a single web application does not need to consider.

We can establish a local session between the system application and the user's browser. The local session maintains the login status of the client and the system application. The local session depends on the global session. The global session disappears and the local session must disappear.

When the user accesses the application, first determine whether the local session exists. If it exists, it is considered to be logged in, and there is no need to go to the authentication center to determine. If it does not exist, will be redirected to the authentication center to determine whether the global session exists. If it exists, the application will be notified, and the application and the client will establish a local session between them. The next time the application is requested, the application will No need to go to the certification center for verification.

2.2 Exit

The user exits from one system and accesses other subsystems, which should also be in exit status. To do this, in addition to ending the local partial session, the application should also notify the authentication center that the user has exited.

After receiving the exit notification, the authentication center can end the global session. When the user accesses other applications, the logged out status will be displayed.

Whether it is necessary to immediately notify all subsystems that have established local sessions and destroy their local sessions can be determined according to the actual project.

Recommended learning: "PHP Video Tutorial"

The above is the detailed content of An in-depth analysis of the method of implementing SSO single sign-on in PHP. For more information, please follow other related articles on the PHP Chinese website!