Token principle and application

Recently because the project needs to develop for third-party use of the API, in the entire architecture design of a link to the API access needs to be authenticated, where I chose the token certification. One: Token advantage (this part is quoted from http://www.sumahe.cn/) 1. No State, scalable

The tokens in the client store is stateless and can be extended. Based on this stateless and not storing session information, a 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. A large number of users may cause some congestion. But don't worry. After using tokens, these problems are solved because tokens himself hold the user's authentication information.

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. Based on standard

When creating a token, 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.

Two. Principle of token

1. Will load payload, and header information for BASE64 encryption, the formation of ciphertext payload ciphertext, header ciphertext.

2. The form of ciphertext will be linked with a period, with the service-side secret key for HS256 encryption, generating signatures.

3. The final token is returned to the service end with a period link signature after the preceding two ciphertext

Note:

(1) When the user requests to carry this token (divided into three parts, header ciphertext, payload ciphertext, signature) to the service side, the server to resolve the first part (header ciphertext), with Base64 decryption, you can know what algorithm used to sign, the resolution found here is HS256.

(2) The server uses the original secret key and cipher text (header redaction + ".") +payload redaction) also carries on the HS256 operation, then uses the generation signature and the token carries the signature to compare, if the unanimous explanation token legal, does not agree the original text to be amended.

(3) to determine whether expired, the client by using Base64 to decrypt the second part (payload ciphertext), you can know the load in the authorized time, as well as the validity period. This compares to the current time to find out if token is out of date. third, the realization of ideas

1. User Login checksum, after successful verification, return token to the client.

2. When the client receives the data, it is saved on the client

3. Each access to the client API is carried token to the server side.

4. The server side uses filter filter check. If the checksum succeeds, the request data is returned and the error code is returned by the checksum failure

Note: If there are errors, please point out that we hope that the common progress