Analysis and implementation of single sign-on cookies in PHP

Single Sign-On SSO (Single Sign-On) is part of identity management. A more popular definition of SSO is: SSO refers to the same user who accesses protected resources in different applications on the same server. He only needs to log in once, that is, after passing the security verification in one application, he can then access protected resources in other applications. When using resources, you no longer need to log in again for verification. Hope this article is helpful to everyone.

What is SSO?

Single Sign-On SSO (Single Sign-On) is part of identity management. A more popular definition of SSO is: SSO refers to the same user who accesses protected resources in different applications on the same server. He only needs to log in once, that is, after passing the security verification in one application, he can then access protected resources in other applications. When accessing resources, there is no need to log in again for verification

Use of SSO:

In the current enterprise application environment, there are often many application systems, such as Taobao, Tmall, Love Taobao and other products such as office automation (OA) systems, financial management systems, file management systems, information query systems, etc. These application systems serve the enterprise's information construction and bring good benefits to the enterprise. However, it is inconvenient for users to use these application systems. Every time a user uses the system, they must enter their user name and password for identity verification; and different application systems have different user accounts, and users must remember multiple sets of user names and passwords at the same time. Especially for enterprises with a large number of application systems and a large number of users, this problem is particularly prominent. The cause of the problem is not a mistake in system development, but a lack of overall planning and a unified user login platform. Using SSO technology can solve the above problems

Benefits of SSO:

User convenience: Consider from the perspective of actual user use

When users use the application system, they can log in once and use it multiple times. Users no longer need to enter user names and user passwords every time, nor do they need to remember multiple sets of user names and user passwords. A single sign-on platform can improve the user experience of using the application system.
Convenient for administrators: from the perspective of daily maintenance and management

Now many large Internet companies have many applications, for example, the following is a screenshot of Taobao:

Tmall, Juhuasuan, Toutiao, etc. are all different applications, and some even use completely different domain names, but all users registered on Taobao use one set of usernames and passwords , if you directly switch between these systems and cannot synchronize the login status, the experience will be very poor. To give another example, many companies have many internal systems, such as HR systems, financial systems, attendance systems, etc. If employees log in to one system and need to log in to jump to another system, it will be very uncomfortable. ..

Based on this, SSO (Single Sign On) came into being. Of course, there are many ways to realize this requirement. Using cookies is one of the simpler ways. The main problem that needs to be solved is: Cookies cannot be transferred across domains. How to notify cookies of one domain to other applications (not in the same application)? a domain)?

So, if you are not familiar with the cookie mechanism, please google it first and get a general understanding of why cookies are designed not to cross domains and other related issues.

System administrators only need to maintain a unified set of user accounts, which is convenient and simple. In contrast, system administrators previously had to manage many sets of user accounts. Each application system has a set of user accounts, which not only brings inconvenience to management, but is also prone to management loopholes.

Simplify application system development: Consider from the perspective of application expansion

When developing a new application system, you can directly use the user authentication service of the single sign-on platform to simplify the development process. The single sign-on platform realizes single sign-on by providing a unified authentication platform. Therefore, the application system does not need to develop user authentication procedures.
How to achieve?

SSO has the following ways to implement

Shared Cookie

When our subsystems are all in one When the browser is under the parent domain name, we can plant the cookie under the parent domain, so that the cookies under the same domain name can be shared by browsers. In this way, the user's Session ID can be obtained through the cookie encryption and decryption algorithm, thereby realizing SSO.

However, we later discovered that this method has several disadvantages:
a. All systems with the same domain name can obtain the SessionID, which is easy to be modified and unsafe;
b. Domain cannot be used.

ticket verification, we currently adopt this method

This implementation of SSO has the following steps:

a. The user accesses a certain subsystem and finds that if he is not logged in, the user will be directed to jump to the SSO login page;
b. Determine whether the SSO has logged in;
c. If already logged in, jump directly to Callback address, and return authentication ticket;
d. If not logged in, the user correctly enters the user name/password, authentication passes and jumps to the callback address, and returns the authentication ticket;
e. The subsystem obtains the ticket and calls SSO Obtain user uid and other information, and let the user log in after success.

As mentioned before, how to implement SSO through cookies is mainly about how to solve cross-domain problems. First, let’s talk about the domain attribute in Set-Cookie.

Cookie domain

In order to allow the Http protocol to maintain context to a certain extent, the server can add Set-Cookie to the response header to write some data. To the client, the

domain field in Set-Cookie is used to indicate the domain where this cookie is located.

Chestnut:

When we visit www.cookieexm.com, if the server adds Set-Cookie in the return header, if the domain is not specified, then this cookie will be defaulted The domain is www.cookieexm.com, that is, the client will return this cookie to the server only when visiting www.cookieexm.com.
If we specify domain as .cookieexm.com, then the client can return cookies when accessing the following domain names: www.cookieexm.com www1.cookieexm.com a.cookieexm.com ***.cookieexm.com.

So, we draw a conclusion: the client matches the domain of the cookie from the end. With this basis, we can implement our SSO login.

Things to note in cookies

is set to http-only

Involving login credentials (such as tickets or user names) should be encrypted

Cookies cannot store private data

Specific solution

Suppose we need to use the following subsystem **.a1.a2 **.b1 To implement single sign-on between .b2 **.c1.c2, first we need an authentication system (sso.s1.s2) specifically for single sign-in. Assume that the system is currently not logged in. Take www.a1.a2 as an example:

Look at the effects of each step separately:

Request www.a1 .a2

www.a1.a2 receives the request and checks whether it carries the login cookie. If it has not logged in yet, it will redirect to the SSO authentication center
SSO provides a login window, and the user enters the username and password. The SSO system verifies the user name and password

This step is key. If the login is successful, the cookie of the SSO system is first placed on the client; at the same time, the user's authentication information is passed to the business party through redirection. , note that this transfer obviously cannot be passed through cookies (different domains), usually through encrypted querystring.

The verification system of the business side receives the SSO authentication information and then performs authentication
After the business side passes the authentication, it writes the cookie of the authentication result to .a1.a2. At this point, the SSO authentication is completed
Redirect to the business system www.a1.a2. From the previous conclusion, all business systems ending with .a1.a2 can use this authenticated cookie

response

Note:
The business authentication system does not necessarily exist. Some systems that are not too sensitive can be redirected directly from SSO Authorization to the business system and bring the SSO authentication information there.

Following the above, at this time, if the user accesses the www.b1.b2 application, as shown in the following figure:

is the same as accessing www.a1.a2 The difference is that we no longer need to enter the user name when redirecting to SSO Authorization, because sso.s1.s2 already has cookies at this time and uses cookie verification directly.

The above is a simple cookie-based login system.

Several of these issues need to be solved with focus

How to efficiently store a large amount of temporary trust data
How to prevent the information transfer process from being tampered with
How to make the SSO system trust the login system and the login system
For the first question, 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, digital signatures are generally used, either through digital certificate signatures or through methods like md5. This requires the SSO system to encrypt the parameters that need to be verified with md5 when returning the login URL. And return it with the token. 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 changed by verifying the token.

For 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.

Related recommendations:

Single sign-on principle and simple implementation

Detailed explanation of the implementation methods of three SSO single sign-on situations

##UCenter single sign-on/synchronous login/synchronous logout examples _PHP Tutorial

The above is the detailed content of Analysis and implementation of single sign-on cookies in PHP. For more information, please follow other related articles on the PHP Chinese website!