What does single sign-on mean?

Single sign-on SSO means that in multiple application systems, users only need to log in once to access all mutually trusted application systems. It is one of the solutions for enterprise business integration. Its advantages: 1. Improve User efficiency; 2. Improve developer efficiency; 3. Simplify management.

#In the very early days of the company, a company might only have one Server, but gradually the number of Servers began to increase. Each Server must be registered and logged in, and when logging out, one must log out one by one. The user experience is very bad! You can imagine that going to Douban and logging into Douban FM, Douban Reading, Douban Movies, Douban Diary... it will really make people collapse. We want another login experience: a company's services only require one registration, one login when logging in, and one logout when logging out. How to do it?

One registration. It’s not difficult to register once. Think about it, is it just a matter of synchronizing user information between servers? Yes, but this description is not complete. We will explain it in detail later when we talk about user registration. In fact, the management of user information is the real difficulty of SSO. But as beginners, our difficulty lies in the technology to implement SSO! Let’s discuss the means of implementation first.

One login and one logout. Looking back at the story of ordinary shopping malls, what is the key thing to keep logged in? Recorder(session)? That kind of paper called a cookie? The ID written on the paper? It is the information recorded in the session and the ID. Cookies are not just a tool for recording IDs. The client holds the ID and the server holds the session, and both are used together to maintain the login status. The client needs to use the ID as a credential, and the server needs to use the session to verify the validity of the ID (the ID may have expired, it may be forged at all and the corresponding information cannot be found, the client corresponding to the ID has not yet performed login verification, etc. ). However, the session is unique to each server at the beginning. Douban FM has its own session, Douban Reading has its own session, and the cookie that records the ID cannot be cross-domain. Therefore, if we want to log in and log out once, we only need to find a way to let each server share the same session information so that the client can hold this ID under each domain name. Going further, as long as each server gets the same ID, there is a way to check the validity of the ID and get the user information corresponding to the ID, that is, it can check the ID;

Single sign-on implementation method

server side

Based on how the server group generates and verifies IDs, it is roughly divided into two types:

"Shared Cookie" This is For the method of sharing session mentioned above, I think it is better to call it "shared session". In essence, cookie is just a medium for storing session-id, and session-id can also be placed in the URL of each request. It is said that this method is unsafe, so I didn’t go into it in details. Can anyone recommend some relevant information? I will add it later. In fact, it is. After all, the session mechanism is one server for each session from the beginning. It is indeed a bit strange to take out the session and let all servers share it.

SSO-Token method Because the method of sharing session is not secure, we no longer use session-id as the identity identifier. We generate another identifier and name it SSO-Token (or Ticket). This identifier is unique to the entire server group, and all server groups can verify the token and obtain the information of the user behind the token. . What we are going to discuss is also this way, and the specific flow chart will be shown later.

Browser side

There is a very critical step in single sign-on. This step has nothing to do with the way of verifying the token on the server side. The earliest "shared session" method is still the current "token" " method, the identity identifier will face such a problem on the browser side: after the user successfully logs in and gets the token (or session-id), how can the browser store and share it to other domain names? The same domain name is very simple. Store the token in the cookie and set the cookie path to the top-level domain name so that all subdomains can read the token in the cookie. This is how to share cookies (this is called shared cookies, the one above should be called shared session). For example: Google, google.com is its top-level domain name, mail.google.com for email services and map.google.com for map services are both its subdomains. But what should we do when going cross-domain? Google also has a domain name, youtube.com, which provides video services.

Recommended tutorial: "PHP"

The above is the detailed content of What does single sign-on mean?. For more information, please follow other related articles on the PHP Chinese website!