The login method we implemented before, after the login is successful, the user information is stored in the server Session, and the newly created SESSIONID is written to the cookie of the browser. However, the cookie is a unique mechanism of the browser. For APP or applet, Cookie+Session The login process of the method is not applicable, then what method should be used at this time?
Comparison of login authentication process
Cookie + Session login process
- The login method we implemented before, after a successful login, the user information is stored in the server Session. Every time the user accesses the service through the browser, it will check whether the browser Cookie exists JSESSIONID, and if it does not exist, a new session will be created on the server. , Write the newly created SESSIONID into the browser's Cookie, so that every time the browser sends a request, it will
根据SESSIONID找到响应的Sessionretrieve the user information. - Illustration:
Token authentication process
- The above method requires the use of browser-specific cookies, but in many cases the server does not interact with the browser, such as APP or applet or even the front and back ends are separated. In the case of separation between the front and back ends, the browser visits first In fact, it is the resource of the Web Server, not the server directly accessed
访问服务器的不再是浏览器了，所以Cookie+Session的方式并不适用. The same applies to APPs and applets . - In fact, the Cookie+Session method is also possible, but there will be several problems:
开发繁琐, Cookie is a mechanism unique to the browser. If you want APP to have a similar mechanism, you need to write more code to implement it.安全性和客户体验差, Because based on the Cookie+Session method, the authentication method is done by the server. In fact, it only needs to obtain the user login information according to the SESSIONID in the Cookie. This leads to the fact that as long as the SESSIONID is available, the server interface can be accessed, and the security is very poor. ; If the session validity time is shortened in order to improve security, then users need to log in frequently, and the customer experience is poor.- Some front-end technologies
不支持Cookie, such as small programs.
- Therefore, a Token authentication method is needed here. In fact, it is similar to the Cookie+Session method. It also needs to give the user an identification Token, but in the Session mode, write JSESSIONID and token in the Cookie. Send a Token directly to the user in the way of
用户每次访问的时候也要带上令牌，而应用服务器不再存储标识，服务器的认证不再基于Session而是基于令牌. - The benefits of this approach:
开发简单, The form of token is actually a string. It only needs to be passed to the backend through parameters (either request header or request body) and brought to the backend without writing some code for Cookie, so the development is simple.安全性和客户体验, First of all, the first way to generate JSESSIONID is done by the server, we can't interfere, but for the latter way, what information can be included in the generation of the token, how to verify these are all controllable, and many technical means can be added to the token. Security, such as shortening the effective time and adding a refresh mechanism at the same time, that guarantees security without affecting the user experience.- For
不支持cookie的这种情况就不存在it.
- Illustration:
Spring Security OAuth
OAuth protocol
- In fact, you will find that the Token authentication method is some operations of the OAuth protocol service provider
Spring Security OAuth就封装了所有服务提供商的一些行为. - OAuth protocol flow chart:
Introduction to Spring Security OAuth
- Illustrated description:
- The service provider's responsibilities , the service provider actually implements the authentication server and the resource server. The authentication server mainly implements four authorization modes. Through the four authorization modes, the application confirms the user's identity and the permissions it has, and then generates and stores the Token based on the authorization information. In the resource server, it is to protect resources (rest services). In fact, it is the Spring Security filter chain that I have been talking about before, and
Spring Security OAuth功能的实现a new filter is added to the filter chainOAuth2AuthenticationProcessingFilter. The function is to take out the Token carried in the request. , Find the corresponding user information according to the previously configured Token storage strategy, and then determine whether the resource can be finally accessed according to a series of judgments such as whether the user information exists. - In the process of our implementation, we will not go to the four authorization modes , because for example, the SMS verification code method does not have much to do with the standard four authorization modes, so what we have to do is
实现自定义的认证，让自定义的认证方式嫁接到认证服务器上去: After SMS authentication, username and password authentication, etc., you can also call the Token generation mechanism to generate Tokens and send them to third-party applications. - The content of the green box in the diagram has been implemented, and what we want to write is what is in the orange box.
OAuth2.0 protocol
- For the OAuth2.0 protocol, please refer to: Spring Security (9): OAuth2.0 protocol