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

This article mainly introduces "what is the principle and data structure of JWT". In daily operation, I believe many people have doubts about what is the principle and data structure of JWT. I have consulted all kinds of materials and sorted out simple and easy operation methods. I hope to help you answer the doubts about "what is the principle and data structure of JWT"! Next, please follow the small series to learn together!

I. Cross-domain authentication issues

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

The user sends a username and password to the server.

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

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

Each subsequent request by the user will pass the session_id back to the server through cookies.

5. The server receives the session_id and finds the data saved in the previous period, thus knowing the identity of the user.

The problem with this pattern is that it doesn't scale well. Of course, there is no problem with stand-alone. If it is a server cluster or a cross-domain service-oriented architecture, session data sharing is required, and each server can read session data.

For example, website A and website B are affiliated services of the same company. Now ask, the user wants to be in only among them website login, visit another website to be able to login automatically again, how to achieve excuse me?

One solution is session data persistence, written to a database or other persistence layer. All services request data from the persistence layer upon receipt of the request. The advantage of this scheme is that the structure is clear, and the disadvantage is that the amount of work is relatively large. In addition, if the persistence layer fails, it will fail at a single point.

Another scenario is that the server simply does not save session data, all data is saved in the client, and each request is sent back to the server. JWT is one example of this approach.

II. Principle of JWT

The principle of JWT is that after the server authenticates, it generates a JSON object and sends it back to the user, just like the following.

{ "Name": "Zhang San", "Role": "Administrator", "Expiration time": "July 1, 2018 0:00"}

In the future, when users communicate with the server, they will send back this JSON object. The server relies solely on this object to identify the user. To prevent users from tampering with the data, the server adds a signature when generating this object (see below).

The server does not store any session data, that is, the server becomes stateless, which makes it easier to scale.

III. Data structure of JWT

The actual JWT looks something like this.

It's a long string with a dot (.) Divided into three parts. Note that there are no newlines inside the JWT, but it is written in a few lines just for ease of presentation.

The three parts of JWT are listed below.

Head (head)

Payload

Signature

Write it in one line, and it looks like this.

These three sections are described in turn below.

3.1 Header

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

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

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

Finally, convert the above JSON object to a string using the Base64URL algorithm (see below).

3.2 Payload

The Payload section 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

Subject (subject): Subject

aud (audience): Audience

nbf (Not Before): Effective time

iat (Issued At): time of issuance

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.

3.3 Signature

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

First, you need to specify a secret. This key is known only to the server and cannot be disclosed to the user. Then, using the signature algorithm specified in the Header (HMAC SHA256 by default), the signature is generated according to the following formula:

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

After calculating the signature, put the three parts of Header, Payload and Signature into a character string, and use "dot"(.) between each part. Separated, it can be returned to the user.

3.4 Base64URL

As mentioned earlier, the algorithm for Header and Payload serialization is Base64URL. This algorithm is basically similar to Base64 algorithm, but there are some minor differences.

JWT acts as a token, and in some cases may be placed in a URL (e.g. api.example.com/? token=xxx）。Base64 has three characters +,/and =, which have special meanings in URLs, so they should be replaced: = is omitted,+ is replaced by-, and/is replaced by_. This is the Base64URL algorithm.

IV. How to Use JWT

The JWT received by the client from the server can be stored in cookies or localStorage.

After that, every time the client communicates with the server, it takes this JWT with it. You can automatically send it in a Cookie, but it can't cross domains, so it's better to put it in the Authorization field of the HTTP request header.

Authorization: Bearer

Alternatively, JWT can be placed in the data body of POST requests when crossing domains.

V. 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. Effective use of JWT can reduce the number of queries the server makes to the database.

(4) The biggest disadvantage of JWT is that since the server does not save session state, it is impossible to revoke a token or change the permissions of a token during use. That is, once a JWT is issued, it remains valid until expiration, unless the server deploys additional logic.

(5) JWT itself contains authentication information, once leaked, anyone can obtain all the rights of the token. To reduce piracy, the JWT should have a shorter expiration date. For some of the more important permissions, the user should be authenticated again when using them.

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

At this point, the study of "what is the principle and data structure of JWT" is over, hoping to solve everyone's doubts. Theory and practice can better match to help you learn, go and try it! If you want to continue learning more relevant knowledge, please continue to pay attention to the website, Xiaobian will continue to strive to bring more practical articles for everyone!

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.