Shulou(Shulou.com)06/03 Report--

This article mainly introduces "what is the composition of JWT". In daily operation, I believe many people have doubts about what constitutes JWT. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubt of "what is JWT made of?" Next, please follow the editor to study!

What is JWT?

Json web token (JWT) is an open standard based on JSON (RFC 7519) for passing declarations between network application environments. The token is designed to be compact and secure and is particularly suitable for single sign-on (SSO) scenarios at distributed sites. The declaration of JWT is generally used to transfer authenticated user identity information between the identity provider and the service provider in order to obtain resources from the resource server, and can also add some additional declaration information necessary for other business logic. The token can also be directly used for authentication or can be encrypted.

Origin

Speaking of JWT, we should talk about the difference between token-based authentication and traditional session authentication.

Traditional session authentication

We know that the http protocol itself is a stateless protocol, which means that if the user provides a user name and password to our application for user authentication, then the user will have to authenticate the user again on the next request, because according to the http protocol, we cannot know which user sent the request, so in order for our application to identify which user sent the request We can only store a copy of the user's login information on the server, which will be passed to the browser in response, telling it to be saved as cookie so that it can be sent to our application on the next request, so that our application can identify which user the request comes from, which is the traditional session-based authentication.

However, this kind of session-based authentication makes it difficult to expand the application itself. with the increase of different client users, independent servers can no longer carry more users, and then the problems of session-based authentication applications will be exposed.

Problems exposed based on session authentication

Session: after each user has been authenticated by our application, our application has to make a record on the server to facilitate the authentication of the user's next request. Generally speaking, the session is stored in memory, and with the increase of authenticated users, the overhead of the server will increase significantly.

Scalability: after user authentication, the server makes authentication records. If the authentication records are kept in memory, this means that users must request on this server for their next request in order to get authorized resources. In this way, the ability of load balancers is limited in distributed applications. This also means that the scalability of the application is limited.

CSRF: because user identification is based on cookie, if cookie is intercepted, users are vulnerable to cross-site request forgery attacks.

Authentication Mechanism based on token

Token-based authentication mechanism is similar to http protocol is also stateless, it does not need to retain the user's authentication information or session information on the server. This means that applications based on token authentication mechanism do not need to consider which server the user has logged in, which facilitates the expansion of the application.

The process goes like this:

The user uses the username and password to request the server

The server verifies the information of the user

The server sends a token to the user through authentication

The client stores the token and attaches this token value to each request

The server validates the token value and returns data

This token must be passed to the server on each request, and it should be stored in the request header. In addition, the server should support the CORS (cross-source resource sharing) policy, which is generally fine with Access-Control-Allow-Origin: * on the server.

So let's get back to the theme of JWT.

What does JWT look like?

JWT is composed of three pieces of information, which are used in the text. The links together make up the Jwt string. It's like this:

The composition of eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQJWT

The first part we call it the head (header), the second part we call it the payload (similar to the objects carried on the plane), and the third part is the signature.

Header

The header of jwt carries two pieces of information:

Declare the type, this is jwt

Algorithms that declare encryption usually use HMAC SHA256 directly

The complete head looks like the following JSON:

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

The header is then encrypted with base64 (the encryption can be decrypted symmetrically), forming the first part.

EyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9playload

Load is the place where valid information is stored. The name seems to refer specifically to the goods carried on the plane, and the valid information consists of three parts.

Declaration of registration in the standard

A public statement

Private declaration

Declaration of registration in the standard (recommended but not mandatory):

Iss: issuer of jwt

Sub: the user for which jwt is targeted

Aud: the party that receives the jwt

Exp: the expiration time of jwt, which must be greater than the issuing time

Nbf: defines when the jwt is not available.

Iat: the issuing time of the jwt

Jti: the unique identity of the jwt, mainly used as an one-time token to avoid replay attacks.

Public statement:

Public statements can add any information, generally adding user-related information or other necessary information needed by the business. However, it is not recommended to add sensitive information because this part can be decrypted on the client side.

Private declaration:

Private declaration is a declaration jointly defined by providers and consumers, and it is generally not recommended to store sensitive information, because base64 is symmetrically decrypted, which means that this part of the information can be classified as plaintext.

Define a payload:

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

Then encrypt it with base64 to get the second part of the Jwt.

EyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9signature

The third part of jwt is a visa information, which consists of three parts:

Header (after base64)

Payload (after base64)

Secret

This part requires the use of base64 encrypted header and base64 encrypted payload. Concatenate the string, then add salt secret combination encryption through the encryption declared in header, and then form the third part of the jwt.

/ / javascriptvar encodedString = base64UrlEncode (header) +'.'+ base64UrlEncode (payload); var signature = HMACSHA256 (encodedString, 'secret'); / / TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Use these three parts. Concatenate into a complete string to form the final jwt:

EyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Note: secret is stored on the server side, and the signing and generation of jwt is also on the server side. Secret is used for jwt signing and jwt verification, so it is your server's private key and should not be revealed in any scenario. Once the client knows about the secret, it means that the client can sign the jwt itself.

How to apply

Generally, Authorization is added to the request header and marked with Bearer:

Fetch ('api/user/1', {headers: {' Authorization': 'Bearer' + token}})

The server validates the token and returns the appropriate resource if the verification passes. The whole process goes like this:

Jwt-diagram

Summarize the advantages

Because of the versatility of json, JWT can be supported across languages, and many languages such as JAVA,JavaScript,NodeJS,PHP can be used.

Because of the payload section, JWT can store some insensitive information necessary for other business logic on its own.

Easy to transmit, the composition of jwt is very simple, and the byte occupation is very small, so it is very easy to transmit.

It does not need to save session information on the server, so it is easy to extend.

Safety related

Sensitive information should not be stored in the payload part of the jwt because that part is decryptable by the client.

Protect the secret private key, which is very important.

If you can, use the https protocol

At this point, the study of "what is the composition of JWT" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.