PHP Single Sign-on SSO implementation method

SSO is a single sign-on that controls access to multiple related but independent systems, and users with this privilege can access one or more systems with a single ID and password to avoid using different usernames or passwords, or to log on to each system seamlessly through a configuration.

Using Single sign-on for large systems can reduce a lot of hassle for users. Take Baidu, Baidu, there are a lot of subsystems-Baidu experience, Baidu know, Baidu Library and so on, if we use these systems, every system needs us to enter the user name and password login once, I believe that the user experience will definitely fall straight.

2 elements that interact with SSO: 1. User, 2. System, it is characterized by: One login, all Access . SSO is a type of access control that controls whether a user can log on, that is, authenticating a user, and that all other systems are authenticated on it, and that the core of SSO at the system level is the 3 elements: 1. User, 2. System, 3. Validation Center.

1, the same domain but different subdomains how to do single sign-on

If our site is deployed according to the following domain name:
Sub1.onmpw.com
Sub2.onmpw.com

These two sites share the same domain onmpw.com.

By default, the browser sends the host for the domain to which the cookie belongs. In other words, the default domain that the cookie from sub1.onmpw.com belongs to IS. sub1.onmpw.com. Therefore, sub2.onmpw.com does not receive any cookie information that belongs to sub1.onmpw.com. Because they are on different hosts, and the subdomains of both are different.

1.1 Set cookie information for both under the same domain

• Login sub1.onmpw.com System

• After successful login, generate a unique identifier token (knowing the token, you know which user is logged in). To set the cookie information, it is important to note that the token is stored in a cookie, but the domain to which the cookie belongs must be set to the top-level domain when set. onmpw.com. Here you can use the Setcookie function, the fourth parameter of the function is used to set the domain of the cookie.

Setcookie (' token ', ' xxx ', '/', '. onmpw.com ');

• Accessing the sub2.onmpw.com system, the browser sends the information token in the cookie to the sub2.onmpw.com system together with the request. The system will first check if the session is logged in, and if not, verify the token in the cookie to enable automatic login.

• Sub2.onmpw.com Log in after the success of writing session information. Later verification will be verified with your session information.

1.2 Sign Out

One problem here is that the SUB1 system exits, except that it can clear its own session information and the cookie that belongs to the domain. onmpw.com. It does not clear the session information of the SUB2 system. That SUB2 is still logged in. This means that although single sign-on can be implemented, it is not possible to exit at the same time. The reason is that sub1 and sub2 can share cookies through the settings of the Setcookie function, but the sessionId of the two is different, and the sessionId is stored as a cookie in the browser, but the domain it belongs to is not. Onmp W.com.

So how do we solve this problem? We know that this problem can be solved as long as the sessionId of the two systems is the same for this situation. This means that the sessionId cookie belongs to the same domain as the. onmpw.com. In PHP, SessionId is generated after the session_start () call. In order for Sub1 and sub2 to have common sessionId, it is necessary to set SessionId's owning domain 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 can be achieved different level two domain name single sign-on and exit.
2, but can also be simplified, such as to ensure that the same sessionId can achieve different level two domain name of the single sign-on and exit.
Reference article: https://www.onmpw.com/tm/xwzj/network_145.html

2. How to achieve single sign-on between different domains

Let's say we need to implement single sign-on between the following stations.

Www.onmpw1.com
Www.onmpw2.com
Www.onmpw3.com

The above plan won't work.

There are open-source SSO solutions on GitHub that are similar in principle to mainstream SSO:
Https://github.com/jasny/sso
Wiki
Demo

Core principle:
1, the client accesses the different subsystems, the subsystem corresponding SSO User Service center uses the same SessionId.
2 . Authorization link binding between subsystem Broker and Server through attach

The same root domain name does not specify the domain name, the first authorization needs to jump to the licensing service each time, but designated domain, the same root domain name as long as there is a successful authorization, you can share the cookie, the next time you do not have to authorize, directly can request user information.

first time access a:

Second visit 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, and we call this session a global session . When users follow the system application, we can not each application request to the certification center to determine whether to log in, so inefficient, this is not a single Web application to consider.

We can establish a local session between the system application and the user's browser, the local session maintains the login state of the client and the system application, the local session is attached to the global session, the global session disappears, and the local session must disappear.

When the user accesses the application, it first determines whether the local session exists, if there is a login status, it is not necessary to judge the authentication center. If it does not exist, redirect to the authentication center to determine whether the global session exists , if present, notify the application, the application and the client to establish a local session between them, the next time the application is requested, the authentication center is not verified.

2.2 Exit

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

The certification center receives an exit notification to end the global session, and when the user accesses another app, the logout status is displayed.

You do not need to immediately notify all subsystems that have established local sessions and destroy their local sessions, depending on the actual project.

SSO, Single Sign-on, is a control over multiple related but independent systems, and users with this privilege can access one or more systems with a single ID and password to avoid using different usernames or passwords, or to log on to each system seamlessly through a configuration.

Using Single sign-on for large systems can reduce a lot of hassle for users. Take Baidu, Baidu, there are a lot of subsystems-Baidu experience, Baidu know, Baidu Library and so on, if we use these systems, every system needs us to enter the user name and password login once, I believe that the user experience will definitely fall straight.

2 elements that interact with SSO: 1. User, 2. System, it is characterized by: One login, all Access . SSO is a type of access control that controls whether a user can log on, that is, authenticating a user, and that all other systems are authenticated on it, and that the core of SSO at the system level is the 3 elements: 1. User, 2. System, 3. Validation Center.

1, the same domain but different subdomains how to do single sign-on

If our site is deployed according to the following domain name:
Sub1.onmpw.com
Sub2.onmpw.com

These two sites share the same domain onmpw.com.

By default, the browser sends the host for the domain to which the cookie belongs. In other words, the default domain that the cookie from sub1.onmpw.com belongs to IS. sub1.onmpw.com. Therefore, sub2.onmpw.com does not receive any cookie information that belongs to sub1.onmpw.com. Because they are on different hosts, and the subdomains of both are different.

1.1 Set cookie information for both under the same domain

• Login sub1.onmpw.com System

• After successful login, generate a unique identifier token (knowing the token, you know which user is logged in). To set the cookie information, it is important to note that the token is stored in a cookie, but the domain to which the cookie belongs must be set to the top-level domain when set. onmpw.com. Here you can use the Setcookie function, the fourth parameter of the function is used to set the domain of the cookie.

Setcookie (' token ', ' xxx ', '/', '. onmpw.com ');

• Accessing the sub2.onmpw.com system, the browser sends the information token in the cookie to the sub2.onmpw.com system together with the request. The system will first check if the session is logged in, and if not, verify the token in the cookie to enable automatic login.

• Sub2.onmpw.com Log in after the success of writing session information. Later verification will be verified with your session information.

1.2 Sign Out

One problem here is that the SUB1 system exits, except that it can clear its own session information and the cookie that belongs to the domain. onmpw.com. It does not clear the session information of the SUB2 system. That SUB2 is still logged in. This means that although single sign-on can be implemented, it is not possible to exit at the same time. The reason is that sub1 and sub2 can share cookies through the settings of the Setcookie function, but the sessionId of the two is different, and the sessionId is stored as a cookie in the browser, but the domain it belongs to is not. Onmp W.com.

So how do we solve this problem? We know that this problem can be solved as long as the sessionId of the two systems is the same for this situation. This means that the sessionId cookie belongs to the same domain as the. onmpw.com. In PHP, SessionId is generated after the session_start () call. In order for Sub1 and sub2 to have common sessionId, it is necessary to set SessionId's owning domain 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 can be achieved different level two domain name single sign-on and exit.
2, but can also be simplified, such as to ensure that the same sessionId can achieve different level two domain name of the single sign-on and exit.
Reference article: https://www.onmpw.com/tm/xwzj/network_145.html

2. How to achieve single sign-on between different domains

Let's say we need to implement single sign-on between the following stations.

Www.onmpw1.com
Www.onmpw2.com
Www.onmpw3.com

The above plan won't work.

There are open-source SSO solutions on GitHub that are similar in principle to mainstream SSO:
Https://github.com/jasny/sso
Wiki
Demo

Core principle:
1, the client accesses the different subsystems, the subsystem corresponding SSO User Service center uses the same SessionId.
2 . Authorization link binding between subsystem Broker and Server through attach

The same root domain name does not specify the domain name, the first authorization needs to jump to the licensing service each time, but designated domain, the same root domain name as long as there is a successful authorization, you can share the cookie, the next time you do not have to authorize, directly can request user information.

first time access a:

Second visit 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, and we call this session a global session . When users follow the system application, we can not each application request to the certification center to determine whether to log in, so inefficient, this is not a single Web application to consider.

We can establish a local session between the system application and the user's browser, the local session maintains the login state of the client and the system application, the local session is attached to the global session, the global session disappears, and the local session must disappear.

When the user accesses the application, it first determines whether the local session exists, if there is a login status, it is not necessary to judge the authentication center. If it does not exist, redirect to the authentication center to determine whether the global session exists , if present, notify the application, the application and the client to establish a local session between them, the next time the application is requested, the authentication center is not verified.

2.2 Exit

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

The certification center receives an exit notification to end the global session, and when the user accesses another app, the logout status is displayed.

The

requires that you do not need to immediately notify all subsystems that have established local sessions and destroy their local sessions, depending on the actual project.