Shulou(Shulou.com)06/03 Report--

What does single sign-on mean? I believe that many inexperienced people are at a loss about this, so this article summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Single sign-on SSO means that in multiple application systems, users only need to log in once to access all the application systems that trust each other. It is one of the solutions for enterprise business integration. Its advantages are: 1, improve the efficiency of users; 2, improve the efficiency of developers; 3, simplify management.

In a very early company, a company may have only one Server, and slowly the Server began to increase. Each Server has to register and log in, and when you exit, you have to exit one by one. The user experience is very bad! You can imagine, on Douban to log in Douban FM, Douban reading, Douban movie, Douban diary. It's really gonna break people down. We want another login experience: a service under an enterprise only needs to register once, log in once, and log out once. How?

One registration. It's not difficult to register once. Think about it as long as you synchronize user information between Server. Yes, but this description is not complete. I will talk about it in more detail when users register later. In fact, the management of user information is the real difficulty of SSO, but as beginners, our difficulty lies in the implementation of SSO technology! Let's first discuss the means of implementation.

One login and one exit. Looking back at the story of an ordinary mall, what is the key to staying logged in? Recorder (session)? That kind of paper called cookie? ID written on paper? It's the information recorded in session and that ID,cookie is not just a tool to record ID. The client holds the ID and the server holds the session, both of which are used to maintain the login status. The client needs to use ID as the credential, and the server needs to use session to verify the validity of the ID (ID may expire, the corresponding information may not be found at all, and the corresponding client under ID has not yet carried out login verification, etc.). But 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 ID cannot cross domains. Therefore, if we want to log in and log out at a time, we only need to find a way to make each server share the information of a session, so that the client can hold the ID under each domain name. Furthermore, as long as each server gets the same ID, there is a way to verify the validity of the ID and get the corresponding user information of the ID, that is, to verify the ID

Implementation method of single sign-on

Server end

There are two ways to generate and verify ID in server groups:

"sharing Cookie" is the way to share session mentioned above. I think it's better to call it "sharing 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 way is not safe, I did not study in detail, which god can recommend the relevant information, I will make it up later. In fact, it is, after all, the mechanism of session is a server and a session from the very beginning, so it is a bit strange to take out session and let all server share it.

SSO-Token way because the way of sharing session is not secure, so we no longer use session-id as the identity. We generate another identity and name it SSO-Token (or Ticket). This identity is unique to the entire server group, and all server groups can authenticate the token and get the information of the user represented behind the token. This is also the way we are going to discuss, and we will come up with the specific flow chart in a moment.

Browser end

There is also a crucial step in single sign-on, which has nothing to do with the way server verifies token. Using the earliest "shared session" method or the current "token" method, identities on the browser side are faced with such a problem: how can the browser store and share them to other domain names after the user successfully logs in to get the token (or session-id)? The same domain name is very simple. Store the token in cookie and set the path of cookie to the top-level domain, so that all subdomains can read the token in cookie. This is the way to share cookie (this is called shared Cookie, the one above should be called shared session). For example: Google, google.com is its top-level domain, mail.google.com of email service and map.google.com of mapping service are its subdomains. But what about cross-domain? Google also has a domain name, youtube.com, which provides video services.

After reading the above, have you mastered the meaning of single sign-on? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.