The development history

1. Individual applications use the Tomcat session mechanism, which is essentially implemented based on the Cookie technology (including JSESSIONID=XXX) of the client and server. What if the client disables cookies? The previous Cookie(JSESSIONID=XXX) is explicitly written after each request URL.

2. Cluster/integrated system Because session only works on one node, you only need to log in to multiple systems once instead of many times, and you need a unified place to store data centrally.

How to implement session with Cookie disabled? Explicitly add the session ID field to each request URL.

First, where does the session ID come from? When the client requests the server for the first time, the server responds with data containing the session ID, which can be entered for each subsequent request. That’s where the session function comes in.

In essence, the session ID is just a request parameter field, no different from any other request parameter field, except that the value of this field is originally returned by the server and is different for each user.

Now the default Cookie technology of the client is disabled, so we can only find a way to pass this parameter to the server as before. It used to be based on the default Cookie technology of the browser client, but now we need to find a way to achieve it. How do you do that? There are two ways to do this.

Best practice is to explicitly concatenate directly after the URL. Best practice is to hide the form field

These two workarounds, known as rewriting urls, involve explicitly adding the session ID field parameter to each request URL.

Blog.csdn.net/u014225431/… Segmentfault.com/q/101000000…

Architecture diagram

Four, deployment diagram of single sign-on (sso) involves the sso authentication center and the subsystem, communication subsystem and sso authentication center needed to exchange tokens, check the token and initiate the cancellation request, therefore subsystem must be integrated sso client, sso authentication center is sso server, the essence of the whole process of single sign-on is the sso client and the server communication process, Describe it as follows

The SSO authentication center can communicate with the SSO client in various ways. The following uses the Simple httpClient as an example, including Web Service, RPC, and restful apis

Summary 1. The communication between nodes is the communication between subsystem and SSO, which is actually the communication between client (sSO-client.jar) and server (sso.war).

2. Sso is essentially a Web project deployed in tomcat’s WAR package

The principle of

Sso 2. Subsystem

Sso only needs to log in to verify the first request, and subsequent requests do not need sso, but directly through the subsystem authentication.

Global session and Local session 1. Sso global session 2. Subsystem local session

How do SSO and subsystems communicate? By token token.

After successful login, the user establishes sessions with the SSO authentication center and each subsystem. The sessions established between the user and the SSO authentication center are called global sessions, and those established between the user and each subsystem are called local sessions. After the local sessions are established, the user does not access the subsystem protected resources through the SSO authentication center. Global sessions and local sessions have the following constraints:

A local session exists, but a global session must exist. A local session does not necessarily have global session destruction, but must be destroyed

You can deepen your understanding of single sign-on (SSO) through the login process of blogpark, Baidu, CSDN, Taobao, etc. Pay attention to the jump URL and parameters during the login process

Logout Procedure 1. Sso logout, that is, global session logout 2. All subsystems logout, that is, local session logout

Agreement OAuth2.0

1.1.0 2.2.0 //2.0 is an upgrade, but not compatible with 1.0

Several characters

From the authorization flowchart, we can see that OAuth 2.0 has four roles: client, resource owner, resource server, and authorization server.

Client: A client is an application that makes a request to a resource server to access a protected resource on behalf of the resource owner. Resource owner: A resource owner is a person who has the ability to authorize a resource. Resource server: The server where the resource resides. Authorization server: provides different for client applications

Token, can be on the same server with the resource server, or can be independent.

Before going into more detail about OAuth 2.0, there are a few specific terms you need to know. They are crucial to understanding the rest of the lecture, especially the pictures.

(1) Third-party application: a third-party application, also called a “client” in this article, that is, the “cloud printing” in the example in the previous section.

(2) HTTP Service: HTTP service provider, referred to as “service provider” in this paper, that is, Google in the example in the previous section.

(3) Resource Owner: The Resource Owner, also called “user” in this article.

(4) User Agent: the User Agent, which refers to the browser in this paper.

(5) Authorization Server: Authorization server, that is, the server specially used by service providers to process authentication.

(6) Resource Server: Resource server, that is, the server where service providers store user-generated resources. It can be the same server or a different server from the authentication server.

The purpose of OAuth is to enable the client to secure and control the user’s authorization and interact with the service provider.

Several patterns

Client Authorization mode The client can obtain access tokens only after obtaining Authorization Grant from users. OAuth 2.0 defines four authorization methods: AuthorizationCode, implicit, Resource owner password credentials, and Client credentials.

1. Authorization code mode // Suitable for front and back authorization codes + token

2. Simplified mode // Suitable for only front end without back end

3. The username and password mode // is suitable for high trust and is rarely used because the username and password are absolutely confidential

https://oauth.b.com/token? grant_type = password & username = username & / / contains the user name password password = password & client_id = client_idCopy the code

4. Client credential mode // Suitable for command lines without clients

https://oauth.b.com/token?
grant_type=client_credentials&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET
Copy the code

Code implementation

www.ruanyifeng.com/blog/2019/0…

The implementation is very simple, in fact, is the first mode – authorization code + token mode, the steps are as follows: 1. Obtaining and responding to the authorization code 2. Obtaining and responding to the token

How does SSO relate to OAuth2.0?

One is the protocol and the other is the implementation of the protocol. Sso is an implementation of the OAuth2.0 protocol.

So which of the four patterns does SSO implement? The first mode – Authorization code mode: authorization code + token token

What is the relationship between third-party login and OAuth2.0?

Third party login is also an implementation of OAuth2.0 protocol.

reference

www.ruanyifeng.com/blog/2014/0… The introduction of / / about www.ruanyifeng.com/blog/2019/0… // It is easier to understand the function of token (i.e. short-term valid password)

www.ruanyifeng.com/blog/2019/0… // Four modes

Code implementation

What is the difference between sso and distributed Session?

The two problems are different. 1. Sso addresses the problem of login authentication user name and password. The integration system must provide a unified login verification center. 2. Session is a problem after successful login, that is, how to save and maintain session. Distributed sessions store session data in a centralized system (cache middleware REDis).

Both problems occurred at different points in time. These are two different questions.

Work to use

Payment systems do not implement SSO, because each system is independent, and the domain name is different, so each system is independent user system. In addition, you start doing SSO late in life.

Instant messaging and portal integration, so it is absolutely necessary to implement a single sign-on system.

Government projects integrate many projects and should logically implement SSO as well.

Third party login

In fact, it is SSO, but using a third party as SSO, rather than its own implementation, without its own user system. Therefore, under normal circumstances, are the use of a third party and local system users bind, rather than just using a third party login, so that the third party login can be convenient and precipitation of their own user system.

reference

www.cnblogs.com/study-every… // Write very well, basically understand an article

www.jianshu.com/p/f5f9196f3… // Jingdong and Taobao both realize their own SSO

Hello-nick-xu.iteye.com/blog/210330… / / implementation

www.infoq.cn/article/ide…