SSO Cookie login analysis and implementation in PHP

What is SSO?

Single Sign-On SSO (Single Sign-On) is part of identity management. A more popular definition of SSO is: SSO means that the same user who accesses protected resources in different applications on the same server 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 to verify

Purpose of SSO:

In the current enterprise application environment, there are often many application systems, such as Taobao, Tmall, Aitaobao and other products and Such as office automation (OA) system, financial management system, file management system, information query system, 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:

Convenient for users: 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: Consider it 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. As 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 Cookies

When our subsystems are all under a parent domain name, we can plant Cookies in Under the parent domain, cookies under the same domain name can be shared by browsers, so that 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 guided to jump to the SSO login page;
b. Determine whether the SSO has logged in;
c. If already logged in, jump directly to the callback address, and Return the authentication ticket;
d. If not logged in, the user correctly enters the username/password, the authentication pass jumps to the callback address, and returns the authentication ticket;
e. The subsystem obtains the ticket, calls SSO to obtain the user uid, etc. 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, Set- The

domain field in the cookie is used to indicate the domain where the cookie is located.

Chestnut:

When we visit www.cookieexm.com, if the server adds Set-Cookie to the return header, and if the domain is not specified, the default domain of this cookie 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.

What should be noted in the cookie

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.b2 **.c1 To implement single sign-on between .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), but is 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 figure below:

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 focused on solving

How to efficiently store a large amount of temporary trust data
How to prevent the information transfer process from being tampered
How to make the SSO system trust 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 third problem Two questions. 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, this token needs to be passed to the SSO system. The SSO system can identify whether the information has been modified by verifying the token.

For the last question, you can pass 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 articles related to SSO Cookie login analysis and implementation in PHP, please pay attention to the PHP Chinese website!