Several ways and principles to implement single sign-on

Table of contents

2. Distributed session method to achieve single sign-on

1. What is single sign-on?

The English name of single sign-on is: Single Sign On (referred to as SSO). It means that in multiple application systems under the same account platform, users only need to log in once to access all mutually trusted systems. In short, multiple systems can be logged in together.

Why do you need a single sign-on system? In some Internet companies, the company may have multiple subsystems, each login is managed in a unified manner, and multiple account information is managed in a unified SSO single-point login authentication and authorization system. For example, Alibaba's Taobao and Tmall are obviously two systems. However, during use, as long as you log in to Taobao, it also means logged in to Tmall. If each subsystem requires login authentication, users would have gone crazy. , so the problem we have to solve is that users only need to log in once to access all mutually trusted application systems.

2. Single sign-on principle

SSO requires an independent certification center. All subsystems log in through the login portal of the certification center. When logging in, bring your own address. The subsystem only accepts authorization from the certification center. Authorization is implemented through tokens. SSO certification center Verify that the user's username and password are correct, create a global session and token, and send the token as a parameter to each subsystem. When the subsystem gets the token, it is authorized and can use it to create a local session. The local session login method is the same as the login of a single system. Same way.

3. Single sign-on implementation method

The implementation plan of single sign-on generally includes: Cookies, Session synchronization, and distributed Session. Currently, the most common methods used by websites are token tokens and distributed Session.

1. Single sign-on based on Cookie+Redis

The simplest single sign-on implementation uses cookies as a medium to store user credentials. After the user logs in to the system, an encrypted cookie will be returned. When the user accesses the sub-application, the cookie will be brought along and authorized to decrypt the cookie and verify it. After the verification is passed, the current user can be logged in.

redis: in key: generate a unique random value (ip, user id, etc.), in value: user data

Analysis of the above picture

1. The user accesses the protected resources of System 1. System 1 finds that the user is not logged in, jumps to the SSO authentication center, and uses his own address as a parameter. 2. The SSO authentication center
finds that the user is not logged in, and directs the user to the login page.
3. The user enters the username and password to submit the login application.
4. The SSO authentication center verifies the user information, creates a session between the user and the SSO authentication center, which is called a global session, and creates an authorization token at the same time.
5. The SSO authentication center jumps with the token. The initial request address (System 1)
6. System 1 gets the token and goes to the SSO certification center to verify whether the token is valid.
7. The SSO certification center verifies the token and returns it valid. Register System 1.
8. System 1 uses this The token creates a session with the user, called a partial session, and returns protected resources
9. The user accesses the protected resources of system 2.
10. System 2 finds that the user is not logged in, jumps to the SSO authentication center, and uses his own address as a parameter.
11. The SSO Certification Center finds that the user has logged in, jumps back to the address of System 2, and attaches the token.
12. System 2 gets the token and goes to the SSO Certification Center to verify whether the token is valid.
13. SSO Certification Center Verification Order token, return valid, register system 2
14. System 2 uses the token to create a partial session with the user, and returns protected resources

Security can be ensured by encrypting cookies, of course, on the premise that the source code is not leaked. If the encryption algorithm of the cookie is leaked, the attacker can forge the cookie to impersonate the identity of a specific user. The second problem is even more flawed, so we have the following distributed session solution.

2. Distributed session method to achieve single sign-on

The process runs:

(1) When the user logs in for the first time, write the session information (user ID and user information), such as using the user ID as the key, into the distributed Session;

(2) When the user logs in again, obtain the distributed Session and see if there is session information. If not, transfer to the login page;

(3) It is generally implemented using Cache middleware, and it is recommended to use Redis, so it has a persistence function, which facilitates loading of session information from the persistent storage after the distributed Session goes down;

(4) When saving a session, you can set the session retention time, such as 15 minutes, and it will automatically time out after it exceeds;

Combined with Cache middleware, the distributed Session implemented can simulate Session sessions very well.

3.Token verification (single sign-on based on jwt+cookie)

Json web token (JWT) is a JSON-based development standard (RFC 7519) implemented for transmitting claims between network application environments. The token is designed to be compact and secure, especially suitable for single sign-on on distributed sites ( SSO) scenario. Simple understanding: JWT is a token that can store data. It cannot be tampered with (jwt will become invalid after tampering).

Because JWT itself can store data, the process of redis storing user information can be eliminated. Only verification and analysis are needed to obtain the login status.

(JWT stores the login status, and the local browser uses cookies to store the JWT. As long as the JWT does not expire, you can normally access various sub-services of the system.)

1. Log in to a certain module of the project. After logging in, generate a string according to jwt rules, include the logged-in user into the generated string, and return the string (1) You can return the string
through cookie
(2) Return the string through the address bar

2. After the front-end receives the token, it stores the token in its own request header or behind the URL, so that every request can be made with the token.

3. Then access other modules of the project, obtain the token in the address bar or request header, and obtain user information based on the string.

4. At the same time, in order to set the expiration time, you can put the token in redis, set the expiration time, and determine expiration.