Authentication based on Token

1. server-based Authentication

We all know that the HTTP protocol is stateless, this stateless means that the program needs to authenticate each request to identify the identity of the client. Prior to this, the program identifies the request by using the login information stored on the server side. This approach is typically done by storing the session.

Some issues that are exposed based on server authentication:

1.Seesion: Each time an authenticated user initiates a request, the server needs to create a record to store the information. As more and more users are sending requests, the overhead of memory is increasing.

2. Scalability: Use Seesion to store login information in the server's memory, with scalability issues.

3.CORS (cross-domain resource sharing): Sharing Cross-domain resources can be a daunting problem when we need to make data available across multiple mobile devices. When you use Ajax to crawl resources from another domain, you can get a stop request. 4.CSRF (cross-site request forgery): When users visit a bank site, they are vulnerable to a cross station request for forgery and can be exploited to access other sites.
Among these problems, scalability is the most prominent. Therefore, it is necessary for us to seek a more effective method.

2. Token based authentication

Using the Token authentication method, you do not need to store the user's logon record on the server side. The approximate process is this:

1. Client login using username and password

2. The server receives the request, verifies the user name and the password Authentication success, the service end will issue a Token, then sends this Token to the client

3. When the client receives the Token, it can store it, such as in the Cookie or in the local Storage, each time the client requests resources from the server, it needs to receive the request with the Token server that is issued by the server, and then verify the client request with the Token, If the validation succeeds, the requested data is returned to the client.
Advantages based on token verification: 1. Stateless, extensible
The token in the client store is stateless and can be extended. Based on this stateless and not storing session information, the load balancer can upload user information from one service to another server. If we save the authenticated user's information in session, each request requires the user to send authentication information (called session affinity) to the authenticated server. When users are large, they can cause

Some jams. 2. Safety

Sending a token in a request instead of sending a cookie can prevent CSRF (Cross station request forgery). Even if the cookie store is used on the client side, it is only a storage mechanism and not a token,cookie for authentication. Do not store the information in the session, let us less of the session operation. The token is time-sensitive and the user needs to be authenticated after a period of time. We also do not need to wait until the token automatically expires, token has a recall operation, through the token revocataion can make a specific token or a group of the same authentication token invalid. 3. Scalability
Tokens can create programs that share permissions with other programs. For example, you can associate a casual social account with your own large (fackbook or Twitter). When you log on to Twitter via the service (we will buffer this process), we can attach the buffer to the stream of Twitter data (we are allowing buffer to post to our Twitter stream).

When using tokens, you can provide optional permissions to third party applications. When a user wants to have another application access their data, we can create our own APIs to derive special permissions from the tokens. 4. Multi-platform cross-domain
We'll talk about it in advance. Cors (cross-domain resource sharing), when extending applications and services, involves a variety of devices and applications.
Have our APIs just serve data, we can also make the "design" choice to serve assets from a CDN.
This eliminates the "issues" CORS brings up after we set a quick header configuration to our application.
As long as the user has a validated token, data and resources can be requested on any domain.

Access-control-allow-origin: *

5. When creating token based on the standard, you can set some options. We'll do a more detailed description in a subsequent article, but the standard usage will be reflected in the JSON Web tokens. The most recent programs and documents are supplied to the JSON Web tokens. It supports a large number of languages. This means that in future use you can really convert your authentication mechanism.