The first public account of this article is CoderMrWu. We share high-quality technical articles and experience every week. Welcome to pay attention to and exchange with you.

A few years ago, “front and back end separation” was the rage in web development, but now it’s becoming the de facto standard. But what exactly is anterior and posterior end separation? Why do we separate the front and back ends?

What is front end separation? Why do we separate the front and back ends?

The separation of front and back ends is more of an architectural concept. In a traditional Web architecture, such as classic MVC, there is a data layer, a logical layer, and a view layer. This view layer, called the front end, maps to the code layer, which is HTML, JS, CSS and other code files. The data layer and the logical layer are more back-end, such as our.java,.go,.py, etc files. These files are within a project and are not developed, tested, or deployed separately.

In a back-to-front architecture, the front end and back end are separated, in separate projects. The front end has dedicated front-end developers to develop and test, and the back end has back-end developers to develop and test, and they interact with each other through apis.

Front and rear end separation has several benefits:

1/ The front and back end staff are decoupled and the front end and back end are respectively handed over to people who are better at doing it, which refines the types of work and makes it more specialized. Front-end staff to care about user experience, UI design, interactive rendering; Back-end people are more concerned with business logic, performance assurance, security, and so on. In terms of project schedule, the front and back ends can be developed in parallel without affecting each other, which speeds up the overall project schedule.

2/ Decouples the front and back end of the code. The back end simply provides API services and no longer interacts with static files. The back-end can use a more complex distributed, microservice architecture to provide better performance and stability. At the same time, in addition to the PC, the mobile terminal can also use the same set of back-end services.

Seeing this, it is understandable that front – and back-end separation is widely used.

It should be noted that not all projects need to be separated from the front and back ends. For example, large projects have a large number of developers and a clear division of labor. In such a team configuration, using the separation of the front and back ends can increase work efficiency and improve system quality. However, when the team members are small and the division of labor is not so clear, the adoption of the architecture of front and back end separation will only increase the development cost and system complexity. The separation of the front and back ends is a good architectural idea, but it depends on the specific business and personnel situation, not blindly follow.

The front and back ends separate common authentication modes

In front – and – back – end separation, the front – and – back interactions are done through apis, where authentication is essential. The authentication modes commonly used in front – end separation are as follows:

  • Session-Cookie
  • Token authentication
  • OAuth(Open License)

The Session Cookie way

Session-cookie is the most commonly used authentication method when developing Web applications. Its certification process generally looks like this:

  • 1/ The user browser sends 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 the user passes the authentication, a session session is created and the user information is saved in the session. Session information can be saved to server files, shared external storage, and databases for query and verification.
  • 3/ The server returns the unique ID of the session to the user’s browser and saves it in a cookie.
  • 4/ When a user requests another page, the browser automatically carries the user’s cookie and initiates an interface request. After receiving the request, the server resolves the sessionID from the cookie and queries the session saved after login based on the sessionID. If the session exists, the user has logged in and is allowed.

This approach is the most commonly used authentication scheme in MVC architecture and can also be used in front and back end separation. Almost all Web frameworks integrate the session-cookie authentication mode by default, and there are mature processing schemes for the security and stability of session-cookie mode.

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

Token way

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

  • 1/ User Logs in using 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 they are correct, the server issues the token and returns the token to the user.
  • 3/ After the user receives the token, it is stored, and the Web service is usually localStrage or cookie.
  • 4/ When a user requests another resource page, the user carries a token, usually puts the token in the header or parameter, and sends the token to the server.
  • 5/ After receiving the token, the server verifies the token and checks whether the user is correct.

JWT(JSON Web Token) is the most commonly used Token authentication method and has become a standard fact of Token authentication. The Token is segmented by JWT so that it can keep a small amount of data, and signature verification is added to ensure the security of the Token. There is a lot of information on JWT online, which will not be repeated here. Do not understand, can refer to the following information:

  • JSON Web Token Tutorial
  • JWT’s official website

Request way

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 has two versions: 1.0 and 2.0. Compared with version 1.0, version 2.0 is the most important authentication and authorization method for users.

OAuth is more of a licensing mechanism. The owner of the data tells the system that it agrees to authorize third-party applications to access the data. The system then generates a short-term access token (token), which can be used in place of a password for third-party applications.

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

Comparative thinking

In addition to OAuth, JWT Auth and session-cookie Auth are the two most commonly used authentication methods. Analyze and compare in the following directions.

scalability

Session-cookie is a stateful service that stores Session information on the server. When expanding server capacity, session sharing needs to be taken into account. Mature solutions to this problem can be solved by session replication, sharing, persistence, etc. Most distributed Web frameworks have integrated solutions. JWT authentication is a stateless service, and the server can be expanded or shrunk at will.

Session-cookie mode is based on cookies, that is, it must be a framework encapsulated by a browser or a browser that supports cookies. It cannot be used on pure mobile devices. JWT, unlike JWT, does not rely on cookies, as long as they are locally available.

security

Two common security issues in Web development are XSS (cross-site scripting attacks) and CSRF (cross-site request forgery). The former uses injected scripts to execute malicious script code on user authentication sites. The latter takes advantage of the browser’s access to the mechanism that automatically carries cookies on the back end to forge requests across sites. XSS can be solved as long as we filter and escape the injection side, and CSRF is our focus.

In the session-cookie authentication mode, the SessionID is stored in the Cookie, which is prone to CSRF attacks. There are integration solutions in most WEB frameworks, such as Django’s CSRFToken, Beego’s xsrfToken, and so on. You are advised to enable the CSRF function of the Web framework when using the session-cookie scheme.

JWT authentication, you can store tokens in cookies or localstorage. Localstorage is recommended to avoid CSRF attacks.

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

  • 1/ JWT is plain-text encoding The encoding of JWT is an encoding of plain-text Base64 that can be decompilated. When transferring information using JWT, do not place important sensitive information and use HTTPS instead.
  • 2 /JWT leak problemResolving JWT leaks is a balancing act. There are three ways to deal with it, from light to heavy, depending on your business importance:
    • Make the expiration time of the JWT so short that leaks do not matter.
    • Design a blacklist mechanism of JWT on the server side to blacklist leaked tokens.
    • Save the signed JWT and invalidate the direct setting when the JWT is leaked.

performance

In the session-cookie scheme, because the back-end service stores Session information, it needs to be queried during authentication, which consumes resources when a large number of authentication is performed. JWT can put the information into the token, only need to verify the decode, use the signature to verify the token, relatively improved efficiency.

From the above three aspects, we analyze the advantages and disadvantages of session-cookie and JWT, as well as some solutions to the problems. I believe you will have their own choice in mind.

Talking about technology without a business scenario is a hooligan. Authentication methods vary according to service scenarios and architecture designs. Here according to my own experience summed up, under what circumstances should use that kind of authentication, we can refer to.

Session-cookie authentication scheme:

  • Web-only projects;
  • The project is less staffed, and both front and back end development will be involved;
  • The front end of the project is not separated completely, and the front end uses the back-end Web framework as a service container to start;

Using the JWT authentication scheme:

  • Sufficient project personnel allocation, clear division of labor;
  • In addition to web terminal, the project also has mobile terminal;
  • Temporary authorization requirements;
  • Pure interaction between back-end systems.

This article focuses on the topic of front and back end separation and shares the authentication scheme when the front and back end separation. These are just general schemes in general. In specific business scenarios, there are many untypical extended authentication schemes that are also excellent. Please comment on your own best authentication schemes.

Refer to and expand on the reading

  • Cookie, Session, Token, JWT
  • Four authentication modes
  • JWT profile
  • Don’t use JWT
  • Stop using JWT as the Session system! It’s problematic and dangerous.
  • A brief explanation of OAuth 2.0
  • OAuth 2.0 in four ways