Shulou(Shulou.com)05/31 Report--

How to start JSON Web Token, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

JSON Web Token (abbreviated JWT) is the most popular cross-domain authentication solution. Its principle and usage are described below.

The problem of cross-domain authentication

Internet service is inseparable from user authentication. The general procedure is as follows.

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

2. After the verification of the server, save the relevant data in the current conversation (session), such as user role, login time, and so on.

3. The server returns a session_id to the user and writes it to the user's Cookie.

4. Every subsequent request of the user will send the session_id back to the server through Cookie.

5. The server receives the session_id, finds the previously saved data, and then knows the identity of the user.

The problem with this model is that the scaling is not good. Of course, there is no problem with a stand-alone machine. If it is a server cluster or a cross-domain service-oriented architecture, session data sharing is required, and each server can read session.

For example, website An and website B are related services of the same company. Now requires that users as long as one of the sites to log in, and then visit another website will automatically log in, how to achieve?

One solution is to persist session data and write it to a database or other persistence layer. After receiving the request, the various services request data from the persistence layer. The advantage of this scheme is that the structure is clear, and the disadvantage is that the engineering quantity is relatively large. In addition, if the persistence layer fails, it will fail at a single point.

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

The principle of JWT

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

{"name": "Zhang San", "role": "Administrator", "expiration time": "00:00 on July 1st, 2018"}

In the future, when the user communicates with the server, the JSON object will be sent back. The server relies entirely on this object to identify the user. 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, making it easier to extend.

Data structure of JWT

The actual JWT looks something like this.

It is a long string separated into three parts by a dot (.). Note that there is no line wrapping inside the JWT, and it is written into a few lines just for presentation purposes.

The three parts of JWT are as follows.

Header (head)

Payload (load)

Signature (signature)

Write it on a line, and that's what it looks like.

Header.Payload.Signature

The following three parts are introduced in turn.

Header

The Header part is a JSON object that describes the metadata of the JWT, usually like this.

{"alg": "HS256", "typ": "JWT"}

In the above code, the alg attribute represents the signature algorithm (algorithm), and the default is HMAC SHA256 (written as HS256); the typ attribute indicates the type of the token (type), and the JWT token is written as JWT.

Finally, the above JSON object is converted to a string using the Base64URL algorithm (see later).

Payload

The Payload part is also a JSON object that holds the data that actually needs to be passed. JWT specifies seven official fields to choose from.

Iss (issuer): issuer

Exp (expiration time): expiration time

Sub (subject): topic

Aud (audience): audience

Nbf (Not Before): effective time

Iat (Issued At): time of issue

Jti (JWT ID): number

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

{"sub": "1234567890", "name": "John Doe", "admin": true}

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

This JSON object is also converted to 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 key (secret). This key is known only to the server and cannot be disclosed to the user. Then, using the signature algorithm specified in Header (default is HMAC SHA256), generate the signature according to the following formula.

HMACSHA256 (base64UrlEncode (header) + "." + base64UrlEncode (payload), secret)

After calculating the signature, the three parts Header, Payload, and Signature are put together into a string. Each part is separated by a "dot" (.), and it can be returned to the user.

Base64URL

As mentioned earlier, the algorithm for serialization of Header and Payload is Base64URL. This algorithm is basically similar to the Base64 algorithm, but with some small differences.

JWT, as a token, may be put into URL in some situations (such as api.example.com/?token=xxx). Base64 has three characters +, / and =, which have a special meaning in URL, so they have to be replaced: = is omitted, + is replaced with -, / is replaced with _. This is the Base64URL algorithm.

How to use JWT

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

Since then, the client will bring this JWT with it every time it communicates with the server. You can send it automatically in Cookie, but it's not cross-domain, so it's better to put it in the header Authorization field of the HTTP request.

Authorization: Bearer

Alternatively, when crossing domains, the JWT is placed in the data body of the POST request.

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) if JWT is not encrypted, secret data cannot be written to JWT.

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

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

(5) JWT itself contains authentication information, and once disclosed, anyone can get all the permissions of the token. To reduce embezzlement, the validity period of JWT should be set to be short. For some of the more important permissions, users should be authenticated again when using them.

(6) in order to reduce embezzlement, JWT should not use HTTP protocol for clear code transmission, but should use HTTPS protocol for transmission.

After reading the above, have you mastered how to get started with JSON Web Token? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.