Talking about the separation of front end and back end and the choice of authentication


In the field of web development, the separation of front end and back end has become the standard of fact. But what exactly is the front and rear separation? Why separate the front and rear ends?

What is front and rear separation? Why separate the front and rear ends?

The separation of front end and back end is more of an architectural concept. In the traditional web architecture, such as the classic MVC, it can be divided into data layer, logic layer and view layer. This view layer is what we call the front-end, which is mapped to the code level, namely, HTML, JS, CSS and other code files. The data layer and logic layer are more back-end parts, such as so on. These files will be in a project and will not be developed, tested and deployed separately.

Talking about the separation of front end and back end and the choice of authentication

In the architecture of front-end and back-end separation, front-end and back-end are separated in different projects. The front-end has special front-end developers to develop and test, while the back-end has back-end developers to develop and test. They interact with each other through API.

Talking about the separation of front end and back end and the choice of authentication

There are several advantages of front and rear separation:

1 / decoupled front and rear staffLet the front-end and back-end to be done by people who are better at it, refine the types of work, and be more specialized. Front end personnel care about user experience, UI design, interactive rendering; back end personnel pay more attention to business logic, performance assurance, security and other aspects. In terms of project schedule, the front end and the back end can be developed in parallel without affecting each other, thus speeding up the overall project progress.

2 / decouples the front and rear codeThe back end only needs to provide API services and no longer interacts with static files. The back-end can use more complex distributed and microservice architectures 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.

As you can see here, the wide application of front and rear separation is understandable.

It should be noted that not all projects need front-end separation. For example, in large-scale projects, there are many developers with clear division of labor. In this kind of team configuration, front-end separation can increase work efficiency and improve system quality. However, if there are few team members and the division of labor is not so clear, then using the front-end and back-end separation architecture will only increase the development cost and system complexity. It is a good idea to separate the front end from the back end. However, it depends on the specific business and personnel conditions. Don’t follow blindly.

Common authentication methods for front end separation

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

  • Session-Cookie
  • Token verification
  • OAuth (open authorization)

Session cookie mode

Session cookie is the most commonly used authentication method when we develop web applications. Its authentication process is generally as follows:

Talking about the separation of front end and back end and the choice of authentication

  • 1 / user browser sends 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 it passes, a session dialog is created and the user information is saved to the session. Session information can be saved to server files, shared external storage, database and other storage, and used for query and verification in the next request.
  • 3 / the server will return the unique ID of the session to the user’s browser and store it in a cookie.
  • 4 / when a user requests other pages, the browser will automatically carry the user’s cookie and initiate an interface request. After receiving the request, the server will resolve the sessionid from the cookie, query the session after login and save the session according to the sessionid. If there is one, it indicates that the user has logged in and released.

This method is the most commonly used authentication scheme in MVC architecture, and can also be used in the separation of front end and back end. Almost all web frameworks integrate session cookie authentication by default, and have mature solutions for the security and stability of session cookie.

The session cookie scheme can be used as the preferred authentication scheme when the current code uses the back-end web framework as the web container driver.

Token method

Token is a common authentication method for interaction between different systems and front-end and back-end architectures. The authentication process of token is as follows:

Talking about the separation of front end and back end and the choice of authentication

  • 1 / the user logs in with the user name and password and sends the user name and password to the server.
  • 2 / the server verifies the user name and password. If it is correct, it will issue a token and return it to the user.
  • 3 / after the user receives the token, it will be stored. The web service is generally localstrap or cookie.
  • 4 / when users request other resource pages, they will carry a token, which is usually put in the header or parameter and sent to the server.
  • 5 / after receiving, the server verifies the token and judges the correctness of the user.

JWT (JSON web token) is the most commonly used token authentication method, which has become the standard fact of token authentication. JWT segmented the token to keep a small amount of data, and added signature verification to ensure the security of the token. There are a lot of materials introduced on JWT online, which will not be repeated here. If you don’t know, please refer to the following information:

OAuth mode

OAuth (open authorization) is an open standard that allows users to authorize third-party websites to access their user information stored in the server. Our common QQ, wechat and other third-party login is the auth authentication method. The OAuth protocol has two versions: 1.0 and 2.0. Compared with version 1.0, version 2.0 has simpler and more secure authorization process. It is also the most important user authentication and authorization method.

OAuth is more like an authorization mechanism. The owner of the data tells the system that it agrees to authorize third-party applications to enter the system to obtain the data. The system generates a short-term token to replace the password for the third-party application.

OAuth is not a common way in the simple separation of front and back end system. It is more used in authorization interaction between different systems.

Comparative thinking

Taking aside the rarely used OAuth, here we compare the first two common authentication methods JWT auth and session cookie auth. Who is the best practice of front-end and back-end separation authentication. Analysis and comparison from the following directions.


Session cookie isStateThe session information is saved in the server. When the server expands the capacity, it is necessary to consider the problem of session sharing. There are mature solutions to this problem, which can be solved by using session replication, sharing, persistence and other methods. Most distributed web frameworks have integrated processing solutions. JWT verification method isStatelessThe server can expand or shrink at will.

Session cookie modeCookie basedIn other words, it must be a browser or a framework encapsulated by a browser that supports cookies, which cannot be used by pure mobile terminals. JWT is different,Don’t rely on cookiesAs long as it can be stored locally.


XSS (cross site scripting attack) and crsf (Cross Site Request Forgery) are two common security problems in web development. The former uses the injection script to the user authentication website to execute malicious script code. The latter uses the mechanism of browser access back-end automatically carrying cookies to forge cross site requests. XSS can be solved as long as we filter and escape the injection end. Crsf is our focus.

In the session cookie authentication mode, because the session ID is saved in the cookie, it is easy to cause crsf attacks. There are integrated solutions in most web frameworks, such as csrftoken of Django and xsrftoken of beego. When using the session cookie scheme, it is recommended to turn on the CSRF function of the web framework.

JWT authentication can store token in cookie or localstorage. Local storage is recommended to avoid crsf attacks completely.

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

  • 1/ JWT is plaintext encodingJWT encoding is a plaintext Base64 encoding, which can be decompiled. When using JWT to transmit information, do not place important and sensitive information. It is better to use HTTPS.
  • 2/ JWT leaksIt is a balance problem to solve the JWT leakage problem. There are three treatment methods from light to heavy, depending on the importance of your business

    • Set the expiration time for JWT to be short, even if it is leaked.
    • The blacklist mechanism of JWT is designed on the server side, and the leaked token can be blacklisted.
    • Save the issued JWT. When JWT is leaked, it will be invalid directly.


The session cookie scheme, because the back-end service stores session information, needs to be queried during authentication. When there is a large number of authentication, it is very resource consuming. JWT can put the information in the token, only need to verify and decode, use the signature to verify the token, and 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 choice.

Regardless of the business scene, talking about technology is playing rogue. Different business scenarios, different architecture designs, and different authentication methods are also different. Here according to my own experience, under what circumstances should the use of that authentication method, you can refer to.

Application of session cookie authentication scheme:

  • The project only has web side;
  • The project personnel allocation is small, and the front and back-end development will participate;
  • The front end uses the back-end web framework as a service container to start;

Using JWT authentication scheme:

  • The project personnel allocation is sufficient and the division of labor is clear;
  • Besides the web side, the project also has mobile terminal;
  • Temporary authorization requirements;
  • Interaction between pure back-end systems.

This paper summarizes and shares the authentication schemes for the separation of front end and back end. These are just general solutions. In specific business scenarios, there are many unconventional extended verification schemes, which are also excellent. Welcome to leave a message to discuss your best authentication scheme.

Reference and extended reading

Talking about the separation of front end and back end and the choice of authentication