- Session knowledge point
http protocol is stateless, so there is no difference between 100 consecutive visits and one visit, and there is no memory. So we can't allow users to log in once every time they visit the website, the session scheme is proposed.
Establish a session for the user through cookie and session, and give him a cookie when the user is authorized successfully, which is the unique session id. For example, PHP will set a name named phpsessid by default for the user who establishes the session. The phpsessid is stored in the cookie and returned to the client. The next time the user requests this cookie, the server will know that the request has just been requested. Log in again.
So how to display user information, where does the information exist? At this time, you can use memory, files, or databases. The requirement is that the data can be obtained with the user's session id. For example, php will store the user session data with the session id abc in /tmp/phpsess_abc by default. 1] In the file, every time you read it, you need to deserialize the data that the program can understand, and you need to serialize it to a persistent data format when you write.
How to realize session sharing?
If your website is stored on one machine, then this problem does not exist, because the session data is on this machine, but what if you use load balancing to distribute requests to different machines? At this time, there is no problem with the session id on the client side, but if the user's two requests to two different machines, and its session data may exist in one of the machines, at this time, the session data will not be available. , So session sharing becomes a problem.
In fact, various web frameworks have already considered this problem, such as asp.NET, which supports modifying the storage medium of session to sql server through configuration files. The session data of all machines are read from the same database, so there will be no inconsistency. The problem; php supports storing session data to a memcache server, you can also manually change the directory where the session files are stored to the nfs network file system to realize file sharing across machines.
There is also a simple method that can be used when the session information does not change frequently. When machine a sets up a user session, post the session data to a cgi of machine b, and the cgi of machine b saves the session data, so that the machine Both a and b will have the same copy of session data
(SessionStorage, pages in the same session can only be accessed, and when the session ends, the data is also destroyed, so sessionStorage is not a persistent local storage, only session-level storage. Only the same window is allowed to access
loacalStorage, Used for persistent local storage, unless the data is actively deleted, the data will never expire. The same source can read and modify localStorage data)
- Token authentication and session are implemented in two
ways: I
studied a springboot security project a few days ago and analyzed the source code. The login authentication mechanism of token is used inside. The main use process is as shown in the figure above. After login, according to security The security algorithm generates a unique token value (based on JWT), then stores it in redis, and sets the expiration time, then returns the token value to the foreground, and saves it in the localStorage. Then every time you visit, you need to submit the token as verification , The interface can be accessed after verification.
Session method:
1. The server session is an object created by the server when the user accesses the application for the first time. It represents a session of the user and can be used to store data. The server assigns a unique sessionid to each session to ensure that each user has a different session object.
2. After the server has created the session, it will return the sessionid to the user's browser through the cookie, so that when the user sends a request to the server for the second time and later, the sessionid will be sent back to the server through the cookie for the server The session object corresponding to the user can be found according to the sessionid.
3. Session usually has an expiration time setting, such as 2 hours. When the expiration time is up, the server will destroy the previous session and create a new session to return to the user. But as long as the user sends a new request to the server within the expiration time, usually the server will extend the expiration time of his corresponding session by another 2 hours based on the current request time.
4. Session does not have the role of session management at the beginning. It can only be used to manage the session after the user has successfully logged in and authenticated and put the user's login credentials into the sesssion object. The logic for managing sessions is also very simple. As long as you get the user's session object and see if there is a credential for successful login, you can determine whether the user has logged in. When the user actively logs out, the login credentials in its session object will be cleared. Therefore, before the user logs in or after logout, or when the session object fails, they must not get the required login credentials.
The advantages and disadvantages of the two login authentication verifications: it
seems that there is no difference between the two login verifications, but in fact they are quite different. The token verification mechanism is more flexible and convenient than the session verification mechanism.
Advantages of token compared with session verification
-
Support cross-domain access: Cookie does not allow cross-domain access, which does not exist for the Token mechanism, provided that the transmitted user authentication information is transmitted through the HTTP header.
-
Stateless (also known as server-side extensible line): The Token mechanism does not need to store session information on the server side, because the Token itself contains the information of all logged-in users, and only needs to store state information in the client's cookie or local medium.
-
More suitable for CDN: You can request all the information (such as: javascript, HTML, pictures, etc.) of your server through the content distribution network, and your server only needs to provide API.
-
Decoupling: No need to bind to a specific authentication scheme. Token can be generated anywhere, as long as you can make a Token generation call when your API is called.
-
Applicable interface cross-platform: When your client is a native platform (iOS, Android, Windows 8, etc.), Cookies are not supported (you need to process them through the Cookie container), then it will be simple to use Token authentication mechanism Much.
-
CSRF: Because you no longer rely on Cookies, you don't need to consider the prevention of CSRF (Cross Site Request Forgery).
-
Performance: A network round trip time (query session information through the database) is always much more time-consuming than a Token verification and analysis calculated by HMACSHA256.
-
No special treatment for the login page: If you use Protractor for functional testing, you no longer need to do special treatment for the login page.
-
Based on standardization: your API can use standardized JSON Web Token (JWT). This standard already has multiple back-end libraries (.NET, Ruby, Java, Python, PHP) and the support of many companies (such as: Firebase, Google , Microsoft)
Although token has so many advantages, it has the disadvantage that it will be more demanding for programmers. Sessions are relatively simple to write, while the token system is slightly more complicated. It is best to use an existing framework to build.
-
sso single sign-
on In the early stage of enterprise development, companies used few systems, usually one or two. Each system has its own login module. It is very convenient for operators to log in with their own accounts every day.
However, with the development of enterprises, the number of systems used has increased. Operators need to log in multiple times when operating different systems, and the account number of each system is different, which is very inconvenient for operators. So, I thought of whether it is possible to log in to one system, and not to log in to other systems? This is the problem to be solved by single sign-on.The full English name of single sign-on is Single Sign On, or SSO for short. Its explanation is: in multiple application systems, you only need to log in once to access other mutually trusted application systems.
As shown in the figure, there are 4 systems in the figure, namely Application1, Application2, Application3, and SSO. Application1, Application2, and Application3 do not have login modules, while SSO only has login modules and no other business modules. When Application1, Application2, and Application3 need to log in, they will jump to the SSO system. The SSO system completes the login and other application systems follow. Signed in. This is fully in line with our definition of single sign-on (SSO).
Single sign-on under the same domain:
An enterprise generally has only one domain name, and different systems are distinguished by the second-level domain name. For example, we have a domain name called a.com, and there are two business systems: app1.a.com and app2.a.com. To do single sign-on (SSO), we need a login system called sso.a.com.
As long as we log in at sso.a.com, app1.a.com and app2.a.com are also logged in. Through the above login authentication mechanism, we can know that logging in in sso.a.com is actually recording the login status in the session of the sso.a.com server, and at the same time in the sso of the browser (Browser). Cookies are written under a.com. So how can we log in app1.a.com and app2.a.com? There are two problems here:
The web system has developed from a single system to an application group composed of multiple systems. The complexity should be borne by the system, not the user. No matter how complex the web system is, it is a unified whole for the user. That is to say, the user accesses the entire application group of the web system as if accessing a single system. Only one login/logout is enough.
Although a single system The login solution is perfect, but it is no longer applicable to multi-system application groups. Why?
The core of the single system login solution is the cookie, which carries the session id to maintain the session state between the browser and the server. But cookies are restricted. This restriction is the domain of the cookie (usually corresponding to the domain name of the website). When the browser sends an http request, it will automatically carry the cookie that matches the domain, not all cookies.
In this case, why not unify the domain names of all subsystems in the web application group under one top-level domain name, such as "*.baidu.com", and then set their cookie domain to "baidu.com". This approach theoretically Yes, even in the early days, many multi-system logins used this method of sharing cookies with the domain name.
However, feasible does not mean good, and there are many limitations in the way of sharing cookies. First, the domain name of the application group must be unified; secondly, the technology (at least web server) used by each system of the application group must be the same, otherwise the key value of the cookie (tomcat is JSESSIONID) is different, and the session cannot be maintained. Logging on language technology platforms, such as between java, php, and .net systems; third, the cookie itself is not secure.
Therefore, we need a brand new login method to realize the login of multi-system application groups. This is single sign
-on. 3. Single sign-on
What is single sign-on? The full name of single sign-on is Single Sign On (hereinafter referred to as SSO), which means that you can log in to one system in a multi-system application group, and you can get authorization in all other systems without logging in again, including single sign-on and single sign-off.
1. Login
Compared with single system login, sso needs an independent authentication center. Only the authentication center can accept the user's user name and password and other security information. Other systems do not provide login entry, and only accept the indirect authorization of the authentication center. Indirect authorization is achieved through tokens. The sso authentication center verifies that the user’s username and password are okay. An authorization token is created. In the next jump process, the authorization token is sent to each subsystem as a parameter, and the subsystem gets the token , That is authorized, you can use this to create a local session, the local session login method is the same as the login method of a single system. This process, which is the principle of single sign-on, is illustrated by the following figure.
Below is a brief description of the above figure
The user accesses the protected resources of system 1, and system 1 finds that the user is not logged in, jumps to the sso authentication center, and uses his address as a parameter. The
sso authentication center finds that the user is not logged in, and directs the user to the login page. The
user enters the user name and password to submit Log in to apply for the
sso authentication center to verify user information, create a session between the user and the sso authentication center, called a global session, and create an authorization token. The
sso authentication center will jump to the original request address with the token (system 1)
system 1 Get the token, go to the sso authentication center to verify that the token is valid. The
sso authentication center verifies the token and returns valid. The registration system 1
system 1 uses the token to create a session with the user, which is called a partial session, and returns protected Resources The
user accesses the protected resources of
system 2 System 2 finds that the user is not logged in, jumps to the sso certification center, and uses his address as a parameter. The
sso certification center finds that the user is logged in, jumps back to the address of system 2 and attaches the command Card
System 2 gets the token and goes to the sso certification center to verify the token is valid. The
sso certification center verifies the token and returns valid. Registration
system 2 uses the token to create a local session with the user and returns the protected resource
user After a successful login, a session will be established with the sso authentication center and each subsystem. The session established between the user and the sso authentication center is called a global session, and the session established between the user and each subsystem is called a local session. After the local session is established, the user visits the sub-system. The protected resources of the system will no longer pass the sso authentication center. The global session and the local session have the following constraints
Local session exists, global session must exist
Global session exists, local session does not necessarily exist
Global session is destroyed, local session must be destroyed
You can deepen your understanding of single sign-on through the login process of blog garden, Baidu, csdn, Taobao, etc., pay attention Observe the jump URL and parameters during the login process.
2. Logout.
Single sign-on naturally also requires single-point logout. Logout in a subsystem will destroy all subsystem sessions. Use the following figure to illustrate that the
sso authentication center has been Monitor the status of the global session. Once the global session is destroyed, the listener will notify all registered systems to perform the logout operation
The following is a brief description of the above picture
The user initiates a logout request to
system 1 System 1 gets the token according to the session id established between the user and system 1, and initiates a logout request to the
sso authentication center. The sso authentication center verifies that the token is valid, destroys the global session, and takes out all the tokens used The registered system address
sso certification center initiates a cancellation request to all registered systems.
Each registration system receives the cancellation request of the sso certification center, destroys the local session
, and guides the user to the login page.
Fourth, the deployment diagram
single sign-on involves the sso certification center and the public The system, the subsystem and the sso authentication center need to communicate to exchange tokens, verify tokens and initiate logout requests. Therefore, the subsystem must integrate the sso client, and the sso authentication center is the sso server. The essence of the entire single sign-on process is The communication process between sso client and server is described in the following figure
There are many ways to communicate between the sso certification center and the sso client. Here is a simple and easy-to-use httpClient, web service, rpc, restful api are all available.
Five, the implementation
is only a brief introduction to the java-based implementation process, and the complete source code is not provided , Understand the principle, I believe you can achieve it yourself. sso adopts a client/server architecture, let’s first look at the functions to be implemented by sso-client and sso-server (below: sso certification center=sso-server)
sso-client
Intercept the request of the user who is not logged in to the subsystem, and jump to the sso authentication center.
Receive and store the token sent by the sso authentication center.
Communicate with sso-server and verify the validity of the token.
Establish a local session to
intercept the user logout request and send it to the sso authentication center Logout request
Receive the logout request sent by the sso certification center and destroy the local session
sso-server
Verify user login information
Create global session
Create authorization token
Communicate with sso-client to send token
Verify sso-client token validity
System registration
Receive sso-client logout request, log out all sessions
Next, we follow the principle step by step Realize sso!
1. sso-client intercepts unlogged requests.
Java intercepts requests in three ways: servlet, filter, and listener. We use filter. Create a new LoginFilter.java class in sso-client and implement the Filter interface, and add the interception of unlogged users in the doFilter() method
Reference:
https://www.jianshu.com/p/75edcc05acfd