SSO Cookie login analysis and implementation in PHP, ssocookie

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, you no longer need to log in again for verification

Purpose of SSO:

In the current enterprise application environment, there are often many application systems, such as Taobao, Tmall, Aitaobao and other products, as well 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-friendly: Consider from the perspective of actual user usage

When using the application system, users 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

Many big Internet companies now have many applications. For example, the following is a screenshot from Taobao:

Tmall, Juhuasuan, Toutiao, etc. are all different applications, and some even use completely different domain names. However, all users registered on Taobao use a set of usernames and passwords. Direct switching between these systems is not possible. The synchronization experience of login status is 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 it?

SSO can be implemented in the following ways

Shared Cookies

When our subsystems are all under a parent domain name, we can plant Cookies under the parent domain, so that cookies under the same domain name can be shared by browsers, so that the user's SessionID 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 easily modified and unsafe;
b. Cannot be used across domains.

Ticket verification, this is the method we currently adopt

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 SSO has logged in;
c. If you are 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 passes and jumps to the callback address, and the authentication ticket is returned;
e. The subsystem obtains the ticket, calls SSO to obtain user uid and other information, and allows the user to 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.

in Set-Cookie

The domain field is used to indicate the domain where this cookie is located.

Chestnut:

We visit www.cookieexm.com. If the server adds Set-Cookie in the return header, and if the domain is not specified, then the default domain of this cookie is www.cookieexm.com, that is, we can only visit www.cookieexm. com, the client will return this cookie to the server.
If we specify the 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 you need to pay attention to when using cookies

Set to http-only

Cookies cannot store private data

Specific plan

Suppose we need to implement single sign-on between the following subsystems **.a1.a2 **.b1.b2 **.c1.c2. First, we need an authentication system (sso. s1.s2). Assuming that the system is currently not logged in, visit www.a1.a2 as an example:

Look at the role of each step separately:

Request www.a1.a2

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

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

The business side’s verification system receives the SSO authentication information and then authenticates
After the business party is authenticated, write 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

Description:
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.

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

The difference from visiting www.a1.a2 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 large amounts of temporary trust data
How to prevent the information transfer process from being tampered
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, the digital signature method is generally adopted, either through digital certificate signing or through a method like md5. This requires the SSO system to perform md5 encryption on the parameters that need to be verified when returning the login URL, and Return with the token. When the trust relationship needs to be verified by the system that is not logged in, 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

As for the last problem, it can be solved through the whitelist. To put it simply, only the systems on the whitelist can request the production trust relationship. Similarly, only the systems on the whitelist can be exempted from login.