preface

In most Web projects, user login, permission management are very basic, core functions, this time to summarize the current commonly used authentication methods.

Cookie

Let’s first look at the definition of cookie in MDN

An HTTP Cookie (also known as a Web Cookie or browser Cookie) is a small piece of data that a server sends to a user’s browser and keeps locally. It is carried and sent to the server the next time the browser makes a request to the same server. Typically, it is used to tell the server whether two requests are from the same browser, such as to keep the user logged in. Cookies make it possible to record stable state information over stateless HTTP protocols.

Cookies are mainly used for the following three aspects:

Session state management (such as user login status, shopping cart, game score, or other information that needs to be recorded) Personalization (such as user custom Settings, themes, etc.) Browser behavior tracking (such as tracking and analyzing user behavior, etc.)

To put it simply, a cookie is a piece of data stored in a browser. When the current end makes a network request using Ajax, the cookie information can be automatically carried in the request header as long as the credentials attribute is set.

Now that we know the basic definition of cookies, let’s look at how the front end uses cookies for authentication.

In modern system authentication, cookies are generally used together with sessions. Session is a mechanism for recording the Session status between the client and server.

When a user enters a user name and password to log in, the front end invokes the login API, and the server generates a session ID to record the user’s login status. This session ID can be used as the simplest cookie. The login network request will send this session ID back to the front end as a cookie, and the front end will store this cookie in the browser, and then carry this cookie when requesting other network requests, so that the server can identify which user is operating and the login information of this user.

Of course, in practice, not only the session ID is used as a cookie, but other information may be mixed in and encrypted.

Cookie-session has the following disadvantages:

  • If there are multiple servers, log in to one of them to generate a session, but the other servers cannot share the session. You need to establish a session database to solve the problem
  • The server needs to record the login status of users. If a large number of users log in, the server overhead increases
  • Vulnerable to CSRF attacks
  • Cookies cannot be carried across domains

Token

Token translates to Token, which records the user’s information. In the Token login authentication system, the server carries the Token every time the client requests the Token. After seeing the Token, the server can know the user who sent the request and process services.

The generation of a Token is similar to that of a cookie. When a client logs in, the server encrypts the user’s login information to generate a string as a Token. To prevent the information from being tampered, the server also generates a signature based on the requested data.

After the client receives the Token message after login, the client carries the Token in each request to complete authentication.

Compare the authentication modes of Token and cookie-session:

  • The first is that the server saves money by not having to record the user’s login status, and there is no need to share data when there are multiple servers.
  • TokenFully managed by applications and independent of browsers, it is not restricted by the same origin policy and can cross domains.
  • CSFR attack cannot be carried out

Token authentication also encrypts the user’s information into the Token. Each time the server receives a request, it takes a certain amount of time to parse the Token, which is an extra cost.

In the Token login system, in order to ensure security, the expiration time of the Token is usually set to be short, usually only one or a few hours. However, when the Token expires and you have to log in again, the experience will be poor. Therefore, a refresh token with a long expiration time generally exists. After the token expires, the refresh token is perceptually refreshed. You need to log in again only after refresh-token and token expire.

Route Permission Management

After a user logs in to the system, permission management may be performed based on the user’s role. This section briefly shares permission management of routes.

The current front-end projects like React or Vue, whether using hash or history routing mode, generally have a routing table configuration, according to which the page can be jumped.

The simplest way might be to hide the jump link from the page based on permissions, but manually entering the URL in the address bar will still lead you to a page without permissions.

On top of this, the route guard can be added to each page where the route jumps to determine whether there is a permission during the jump. If there is no permission, the route guard will jump to the pre-set page.

Of course, this method is still complicated, so a more reasonable solution is to dynamically generate routing tables. The function of dynamically generating routing tables can be completed in the front end or the back end. After logging in to the backend, the routing table generated based on the permission is directly sent to the front-end. The front-end can use the routing table directly. If handled by the front end, the back end returns specific user role information to the front end, which generates routing tables based on permissions for use.

conclusion

There are many other ways of front-end authentication, such as JWT (actually a Token),OAuth(open authorization), etc. Cookie-session and Token are the two most commonly used. In addition to login authentication, there is also routing permission management. In terms of service details, there may be more specific permission management and control, and the implementation methods are different.