Article From:

The so-called JWT is JSON web token, which is now used for user authentication.

The traditional cookie plus session authentication process is as follows:

1.The user enters the account password and sends it to the server.

2.After the server validates the account password successfully, it creates a Session, stores the Session ID in the Cookie, and the cookie returns to the client with the response. General situationThe SessionID contains browser information and the web application information under the session server. The implementation code is as follows


Note: When you create a session using request. getSession (), you first check that the cookie in the request contains the JSESSION ID (which should be implemented in the web container), and when there is no JSESSIONID considers this to be the first request and creates a new session; if the cookie in the request contains a JSESSION ID, the corresponding session is fetched directly from memory.

3.In subsequent requests, the browser sends the session ID to the server, and if the session with the corresponding ID is found on the server, the server returns the required data to the browser.

4.When the user logs out, the session will be destroyed at both the client and server side.


There are two deficiencies in this authentication method.

1、The server side should keep session information for each user, connect users more, server memory pressure is enormous

2、Not suitable for distribution


JWTIt contains three parts of use. Partition: Header header Payload load Signature signature.

Its structure looks like this Header.Payload.Signature.


In header, there are usually two parts: token type and encryption algorithm. {“alg”: “HS256”, “typ”: “JWT”}, then use this part of the content.Base64Url Coding forms the first part of the JWT structure.


TokenThe second part is the load, which contains claims. Claim is the state of some entities (usually users) and additional metadata. There are three types of claims:reserved, public andprivate.Reserved claims: These claims are predefined by JWT and are not mandatory in JWT, but are recommended. They are commonly used as ISS (issuer), exp (expiration timestamp), sub (user-oriented), aud (receiver), IAT (issuance time).Public claims:Define your own fields as needed, and avoid conflicts.Private claims:These are custom fields that can be used to exchange information loads between two parties: {“sub”: “1234567890”, “name”: “John Doe”, “admin”: true} The above loads need to passBase64UrlIt is encoded as the second part of the JWT structure.


To create a signature, you need to use the encoding header, payload, and a secret key to sign using the signature algorithm specified in the header. For example, if you want to use the HMAC SHA256 algorithm, then the signature should be created in the following way: HMACSHA256 (base64UrlEncode (header) + “.” base64UrlEncode (payload), secret) signature is used to verify that the sender of the message and that the message has not been tampered with. Complete JWThe output of the complete JWT format is a. separated three-segment Base64 encoding, and JWT is easier to pass in HTTP and HTML environments than XML-based standards such as SAML. The following JWT shows a complete JWT format that splits the previous He.Ader, Payload and secret key signature:


Link of this Article: JWT

Leave a Reply

Your email address will not be published. Required fields are marked *