Tokens is the best way to handle authentication across multiple users in most Internet companies that use Web APIS. The following features allow you to use token-based authentication in your applications

1. Stateless and extensible

2. Support mobile devices

3. Cross-program invocation

4. Security

The origin of the Token

Before introducing the principles and advantages of token-based authentication, let’s take a look at what has been done before.

  • Server-based authentication

We all know that the HTTP protocol is stateless, which means that the program needs to verify every request to identify the client.

Until now, applications have identified requests based on login information stored on the server. This is usually done by storing sessions.

  • 1.Seesion: Each time an authentication user initiates a request, the server needs to create a record to store information. As more and more users make requests, the memory overhead increases.

2. Scalability: Seesion is used to store login information in the server memory, which brings scalability problems.

3.CORS(Cross-domain resource sharing) : When we need to use data across multiple mobile devices, cross-domain resource sharing will be a headache. When using Ajax to fetch resources from another domain, requests can be disabled.

4.CSRF(Cross-site request forgery) : when users visit bank websites, they are vulnerable to cross-site request forgery and can be used to access other websites.

Of these, extensible rows are the most prominent. Therefore, it is necessary for us to seek a more effective method.

Token-based authentication principle

Token-based authentication is stateless and we do not store user information on the server. This concept solves many problems when storing information on the server side. NoSession means that your application can add and subtract machines as needed without worrying about whether the user is logged in or not.

Token-based authentication is performed as follows:

1. The user sends a request using the user name and password.

2. Verify the server program.

3. The server program returns a signed token to the client.

4. The client stores the token and carries the token to the server each time it accesses the API.

5. The server verifies the token. If the verification succeeds, the server returns the request data; if the verification fails, the server returns an error code.

The advantage of Tokens

  • Stateless and extensible

Tokens stored on the client side are stateless and scalable. Based on this statelessness and not storing Session information, the load balancer can transfer user information from one service to another. Tokens hold their users’ verification information on their own.

  • security

Sending tokens instead of cookies in a request prevents CSRF(cross-site request forgery). Even if a cookie is used to store tokens on the client side, the cookie is only a storage mechanism and is not used for authentication. By not storing information in the Session, we have less access to the Session.

Tokens are time-limited and users need to re-verify them after a certain period of time.

  • scalability

Tokens creates programs that share permissions with other programs.

  • Multiple platforms cross domains

Let’s start by talking about CORS(Cross-domain resource Sharing), which involves a wide variety of devices and applications when extending applications and services.

Do I need to set the validity period?

For this question, let’s look at two examples. One example is login passwords, which are generally required to change periodically to prevent leakage, so passwords have an expiration date; Another example is security certificates. SSL security certificates have a validity period to address revocation issues. So whether for security reasons or for revocation reasons, tokens need to have an expiration date.

  • How long is the period of validity?

Suffice it to say, keep it as short as necessary for the security of the system, but not too short

  • Then a new problem arises. If the user’s Token expires in the course of normal operation, the user is required to log in again… Isn’t the user experience terrible?

One option is to use Refresh Token, which avoids frequent read and write operations. In this solution, the server does not need to Refresh the expiration time of the Token. Once the Token expires, the server reports to the front end, and the front end applies for a new Token to continue using the Refresh Token. In this solution, the server only needs to check the Refresh Token validity once when the client requests to update the Token, greatly reducing the operation of the update validity period and avoiding frequent read and write operations. Of course, the Refresh Token has an expiration date, but it can be longer, for example, in days.

  • Sequence diagram representation

The sequence diagram for using Token and Refresh Token is as follows:

  1. The login
  2. Business requests
  3. The Token expired. Procedure

    There is no mention in the sequence diagram above of what happens when the Refresh Token expires. Obviously, however, now that the Refresh Token has expired, it is time to ask the user to log in again.

Token summary is used in the project

With token-based authentication, there is no need to store a user’s login record on the server. The general process is like this:

1. Use the user name and password to request the first login

2. The back-end server receives a request to verify the user name and password

3. After the authentication succeeds, the server generates a Token based on the user ID, user name, defined key, and expiration time and sends the Token to the front end

4. The front-end receives the returned Token and stores it, for example, in a Cookie or Local Storage

exportinterface User { token: string; userInfo: UserInfo | any; companyInfo: CompanyInfo | any; resources? : string[]; }Copy the code
save(key: string, value: any, storageType ? : StorageType) {return this.storageService.put(
        {
            pool: key,
            key: 'chris-app',
            storageType: StorageType.localStorage
        },
        value
    );
}
this.storageService.save(CACHE_USER_KEY, user);
Copy the code

5. Check whether localStroage has a token for each route forward. If no token is displayed, the login page is displayed. Some request to obtain user information, change the login state; 6. Each time the front-end requests resources from the server, it carries the Token signed by the server in the request header

HttpInterceptor => headers = headers.set('token', this.authService.getToken());
Copy the code

7. The server receives the request and verifies the Token in the front-end request. No or token expired, return 401. If the validation succeeds, the requested data is returned to the front end.

8. The front end obtains the 401 status code and redirects to the login page.

HttpInterceptor => 
    401: 'User login status invalid, please log in again. '
Copy the code