Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "what is the way of front-end separation and authentication selection". In the operation of actual cases, many people will encounter such a dilemma. Next, let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

What is front and rear separation? Why are the front and rear ends separated?

The separation of front and rear ends is more of an architectural concept. In the traditional web architecture, such as the classic MVC, it is divided into data layer, logic layer and view layer. This view layer, which is what we call the front end, is mapped to the code level, that is, html, js, css and other code files. The data layer and logic layer are more back-end parts, such as our .java, .go, .py and other files. These files will be in a project and will not be developed, tested, or deployed separately.

In the architecture where the front and back ends are separated, the front end and the back end are separate, in different projects. The front end has dedicated front-end developers for development and testing, while the back-end has back-end developers for development and testing, and they interact with each other through API.

Front and rear separation has several benefits:

1 / decoupled the front-end and back-end staff so that the front-end and back-end are respectively handed over to people who are better at it, which refines the types of work and can be more specialized. Front-end staff are concerned about user experience, UI design, interactive rendering, while back-end staff pay more attention to business logic, performance guarantee, security and other aspects. In terms of project schedule, the front and back ends can be developed in parallel without affecting each other, speeding up the overall project progress.

2 / decoupled the front and back end of the code, the back end only needs to provide API services and no longer interact with static files. The back end can use a more complex distributed, micro-service architecture to provide better performance and stability. At the same time, in addition to the PC end, the mobile end can also use the same set of back-end services.

See here, front and rear separation is widely used can also be understood.

We need to note that not all projects need front-end separation, such as large-scale projects, a large number of developers, a clear division of labor, this kind of team configuration, the use of front-end separation can increase work efficiency and improve system quality. However, when the team is small and the division of labor is not so clear, adopting the architecture of separation of front and rear ends will only increase the development cost and system complexity. Front and rear separation is a good architectural idea, but it depends on the specific business and personnel situation, do not blindly follow.

Common authentication methods for separation of front and rear ends

In the front-end separation, the front-end and back-end interaction is carried out through API, so the authentication is indispensable. The following authentication methods are commonly used in front-end separation:

Session-Cookie

Token verification

OAuth (Open Licensing)

Session-Cookie mode

Session-Cookie is the most commonly used authentication method when we develop web applications. Its authentication process generally goes like this:

1 / the user browser initiates an authentication request to the server and sends the user name and password to the server.

2 / the server authenticates the user name and password, if passed, creates a session dialog, and saves the user information to session. The information of session can be saved to server file, shared external storage, database and other storage, and used for query and verification in the next request.

3 / the server will return the unique identity ID of the session to the user's browser and save it in the cookie.

4 / when a user requests another page, the browser automatically carries the user's cookie and initiates an API request. After receiving the request, the server parses the sessionID from the cookie, and queries the logged-in and saved session according to this sessionID. If there is any, the user is logged in and released.

This method is the most commonly used authentication scheme in MVC architecture, and it can also be used in front-end separation. Almost all Web frameworks integrate Session-Cookie authentication by default, and there are mature solutions for the security and stability of Session-Cookie.

When the current end code uses the back-end web framework as the web container driver, the Session-Cookie scheme can be used as the preferred authentication scheme.

Token mode

Token is a common authentication method for different systems to interact with each other and front-end architecture. The authentication process based on Token is as follows:

1 / the user logs in with a user name and password and sends the user name and password to the server.

2 / the server verifies the user name and password and, if correct, issues a token and returns it to the user.

3 / after the user receives the token, store it. The web service is usually localStrage or cookie.

4 / when users request other resource pages, they will bring token, which is usually put in the header or parameters and sent to the server.

5 / after the server receives it, verify the token and judge the correctness of the user.

JWT (JSON Web Token) is the most commonly used way of Token authentication, which has become the standard fact of Token authentication. Token is segmented in JWT mode so that it can keep a small amount of data, and signature verification is added to ensure the security of token. JWT introduces a lot of information on the Internet, so I won't repeat it here. For those who do not understand, please refer to the following materials:

JSON Web Token getting started tutorial

JWT official website

OAuth mode

OAuth (Open Authorization) is an open standard that allows users to authorize third-party websites to access their user information stored on the server. Our common QQ, Wechat and other third-party login is Auth authentication. The OAuth protocol is available in versions 1. 0 and 2. 0. Compared with version 1.0, the whole authorization verification process of version 2.0 is simpler and more secure, and it is also the most important way of user authentication and authorization.

OAuth is more like an authorization mechanism. The owner of the data told the system that it agreed to authorize third-party applications to enter the system and obtain the data. The system thus generates a short-term entry token (token), which is used instead of the password for use by third-party applications.

In the simple front-end separation system, OAuth is not a common way, it is more used in the authorization interaction between different systems.

Comparative thinking

Excluding the less commonly used OAuth, here we compare the first two commonly used authentication methods, JWT Auth and Session-Cookie Auth, to find out who is the best practice of front-end separation authentication. Analyze and compare from the following directions.

Expandability

Session-Cookie is a stateful service that stores session information on the server side. When expanding the capacity of the server, the sharing problem of session needs to be taken into account. There are mature solutions to this problem, which can be solved by session replication, sharing, persistence and so on. Most distributed Web frameworks have integrated processing solutions. JWT verification is a stateless service, and the server can scale up or down at will.

The Session-Cookie approach is based on Cookie, that is, it must be a framework encapsulated by browsers or browsers that support Cookie, and cannot be used on pure mobile devices. Unlike JWT, it does not depend on Cookie, as long as it can be stored locally.

Security.

Two common security issues in Web development are XSS (cross-site scripting attack) and CRSF (cross-site request forgery). The former uses the injection script to the user authentication website to execute malicious script code. The latter uses the mechanism of automatically carrying cookie at the back end of browser access to forge requests across sites. XSS can be solved as long as we filter and escape the injection side, and CRSF is our focus.

In Session-Cookie authentication, because the SessionID is saved in Cookie, it is easy to cause CRSF attacks. There are integrated solutions in most WEB frameworks, such as Django's csrftoken, Beego's xsrfToken, and so on. It is recommended to enable the csrf function of the web framework when using the Session-Cookie solution.

JWT certification, Token can be stored in Cookie or localstorage. The existence of localstorage is recommended so that CRSF attacks are completely avoided.

In addition, JWT has several security issues, which need to be noted:

1 / JWT is plaintext coding JWT is a plaintext Base64 coding, can be decompiled. When using JWT to transmit information, do not place important and sensitive information, it is best to use https.

2 / JWT leak problem solving the JWT leak problem is a balanced problem. There are three ways to deal with it from light to heavy, depending on the importance of your business:

Set the expiration time of JWT to be very short, even if the leak does not matter.

Design the blacklist mechanism of JWT on the server side, and blacklist the leaked Token.

Save the issued JWT. When the JWT is leaked, the direct setting becomes invalid.

Performance

Session-Cookie scheme, because the back-end service stores Session information, it needs to be queried during authentication, which is very resource-consuming when there are a large number of authentication. JWT can put the information into the token, only need to verify the decoding, use the signature to verify the token, relatively speaking, the efficiency will be improved.

From the above three aspects, we analyze the advantages and disadvantages of Session-Cookie and JWT, and some solutions to the problems. I believe that everyone will have their own mental choice.

Putting aside the business scene and talking about technology is a hooligan. Different business scenarios, different architecture designs, applicable authentication methods are also different. Here, according to my own experience, we can refer to what kind of authentication should be used under what circumstances.

Situations where the Session-Cookie certification scheme is applicable:

The project is only on the web side.

The staffing of the project is small, and both front and rear developers will be involved.

The front and rear ends of the project are not completely separated, and the front end uses the back-end web framework as the service container to start.

Using the JWT authentication scheme:

The project has sufficient staffing and clear division of labor.

The project has a mobile terminal in addition to the web terminal

Temporary authorization requirements

Pure interaction between back-end systems.

This is the end of the content of "what is the choice of front and rear separation and authentication". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.