In order to simplify the logic, before talking about single sign-on, let’s introduce a simple single system login

Simple single system login mechanism

It is mainly introduced based on two questions:

1. Why log in?

This reason is more, different systems have different logic, simple list 2, for example: 1. The most common restriction is that a background system displays different menu operation items 2 according to different login roles. Need to save user information, the most common is favorites, payment orders, etc

2. How do I determine whether some users log in?

HTTP is a stateless protocol. What is a stateless protocol?

Stateless means that when the browser sends a request to the server, the server responds to the client’s request. But when the same browser sends the request to the server again, the server doesn’t know it’s the same browser

Therefore, in order to know which user has accessed the network before, various network software providers propose a concept: Session mechanism The flow of the session mechanism is as follows

On the server side, use session to create a session, and on the browser side, use cookie to store session ID. The process is as follows

In this way, the server knows who the last user was, and can also determine which users logged in. The server only needs to save the login status in the session

A quick summary:

The standard HTTP protocol does not include cookies, sessions, and applications, which are not standard protocols. However, various web application providers have proposed and implemented the session mechanism in order to understand the last visitor. Various programming languages, Web containers, and so on, all support it by default. The front-end is based on cookies and the server is based on sessions

But as the business became more and more complex, the following situation gradually emerged:

Not only does the user dislike the trouble, the boss also does not allow the boss to say that I want this:

So, this leads to our protagonist: single sign-on

Single sign-on for multiple systems

What is single sign-on

What Single Sign On (SSO) does: Multiple sites can automatically identify their online status by entering a password at once

Single sign-on and multi-platform logon

The key point of sso is user authentication (storage trust authentication trust). Scenario: Multiple systems automatically log in

The key point of multi-platform login is user authorization OAuth2.0. Scenario: three-party login, such as wechat login

How to implement single sign-on
  1. Single sign-on (SSO) in the same root domain, such as A.baidu.com and B.baidu.com

In this case, the implementation of single sign-on is relatively simple, just need to set the cookie access is based on the root domain (baidu.com), this method of single sign-on has the following defects:

  • The application group domain name must be uniform: the root domain must be the same
  • The web server must be the same: Otherwise, the cookie key value (tomcat JSESSIONID) is different, and the session cannot be maintained
  • The cookie itself is not secure: click here
  1. Single sign-on in different root domains, such as a.com and b.com

Obviously, this problem cannot be solved by cookies. In this case, an intermediary is needed: Central Authentication Service (CAS). The specific process of an independent SSO system is as follows:

Small question: After SSO system login, when I jump back to the original business system with a parameter token, the business system needs to take the token to access SSO again for verification, is it unnecessary? Why is that? Explanation to the end

After login, the cas-based logout process is as follows:

To summarize the characteristics of cas-based sessions:

1. If a local session exists, a global session must exist

2. Global sessions exist, but local sessions do not necessarily exist

3. Global session destruction, local session must be destroyed

Finally, one more point: session management mechanism

Session Management Mechanism

1. Server Session-based management

2. Cookie-based management mode

3. Token-based management mode

It can be seen that token-based and cookie-based methods are basically the same, except that they are not implemented through cookies. Instead, they choose the storage location and put their tokens into the header parameters. Now, they are basically in this way, whether it is front-end SPA or native APP

There is also a ready-made solution standard for token-based management, namely JWT(JSON-Web-Token). JWT does not have any technical implementation, but only defines how token-based management should be implemented. It specifies the standard content that a token should contain as well as the token generation process and method

The final answer to the question left in the article is that the answer is definitely not superfluous. It would be a problem if the user brought a token directly to the authentication authority, so there is still a need to verify the validity of the token

Note: Source of some picturesZhihu liuThanks for the likes