JWT is the abbreviation of JSON web token. It is a JSON object that can be safely transmitted based on RFC 7519 standard.

Cross domain authentication

Internet services are inseparable from user authentication. The general process is as follows.

1. The user sends the user name and password to the server.

2. After the server is verified, relevant data, such as user role, login time, etc., are saved in the current session.

3. The server returns a session to the user_ ID, write the user's cookie.

4. Each subsequent request of the user will pass the cookie to the session_ ID is returned to the server.

5. The server received a session_ ID, find the previously saved data, so as to know the user's identity.

The problem with this model is poor scalability. Of course, there is no problem with a single machine. If it is a server cluster or a cross domain service-oriented architecture, it requires session data sharing, and each server can read sessions.

For example, website a and website B are related services of the same company. Now it is required that users log in to one website and then visit another website to log in automatically. How do you realize it?

One solution is session data persistence, which is written to the database or other persistence layer. After receiving the request, various services request data from the persistence layer. This scheme has the advantages of clear architecture and large quantities. In addition, if the persistence layer hangs, it will fail at a single point.

Another solution is that the server simply does not save session data. All data is saved on the client and sent back to the server every request. JWT is a representative of this scheme.

JWT principle

The principle of JWT is that after the server authenticates, a JSON object is generated and sent back to the user, as shown below.

In the future, the JSON object will be sent back when the user communicates with the server. The server relies entirely on this object to identify the user. In order to prevent users from tampering with data, the server will add a signature when generating this object (see later).

The server does not save any session data, that is, the server becomes stateless, so it is easier to expand.

Format of JWT

Header. Payload. Signature

Header

The header part is a JSON object that describes the metadata of JWT, usually as follows.

In the above code, the alg attribute represents the signature algorithm, and the default is HMAC sha256 (written as hs256); the typ attribute represents the type of the token, and JWT tokens are uniformly written as JWT.

Finally, convert the above JSON object into a string using the base64url algorithm (see later).

Payload

The payload part is also a JSON object, which is used to store the actual data to be transferred. JWT specifies 7 official fields for selection.

In addition to official fields, you can also define private fields in this section. The following is an example.

Note that JWT is not encrypted by default and can be read by anyone, so don't put secret information in this part.

The JSON object should also be converted into a string using the base64url algorithm.

Signature

The signature part is the signature of the first two parts to prevent data tampering.

First, you need to specify a secret. This key is only known to the server and cannot be disclosed to the user. Then, use the signature algorithm specified in the header (HMAC sha256 by default) to generate a signature according to the following formula.

After the signature is calculated, the header, payload and signature are combined into a string. Each part is separated by a dot (.) and can be returned to the user.

Base64URL

As mentioned earlier, the header and payload serialization algorithm is base64url. This algorithm is basically similar to Base64 algorithm, but there are some small differences.

As a token, JWT may be placed in the URL on some occasions (such as API. Example. COM /? Token = XXX). Base64 has three characters +, / and =, which have special meanings in the URL, so it needs to be replaced: = is omitted, + is replaced with -, / is replaced with. This is the base64url algorithm.

How JWT is used

The client receives the JWT returned by the server, which can be stored in cookie or localstorage.

After that, the client should bring this JWT every time it communicates with the server. You can send it automatically in the cookie, but it can't cross domains, so it's better to put it in the authorization field of the header information of the HTTP request.

Another way is to put JWT in the data body of post request when cross domain.

Several characteristics of JWT

(1) JWT is not encrypted by default, but it can also be encrypted. After the original token is generated, it can be encrypted again with the key.

(2) Secret data cannot be written to JWT without encryption.

(3) JWT can be used not only for authentication, but also for exchanging information. The effective use of JWT can reduce the number of server queries to the database.

(4) The biggest disadvantage of JWT is that because the server does not save the session state, it cannot revoke a token or change the permission of the token during use. That is, once the JWT is signed, it will always be valid until it expires, unless the server deploys additional logic.

(5) JWT itself contains authentication information. Once it is leaked, anyone can obtain all the permissions of the token. In order to reduce embezzlement, the validity period of JWT should be set relatively short. For some important permissions, users should be authenticated again.

(6) In order to reduce embezzlement, JWT should not use HTTP protocol for explicit transmission, but HTTPS protocol for transmission.