What is Json Web Token

According to the official website, JWT is an open standard (RFC 7519) that defines a compact, self-contained scheme for securely passing JSON-formatted information between the client and server.

Advantages

  • Small size, and therefore fast transmission
  • There are various transmission modes, such as URL, POST parameter, or HTTP header
  • Rigorous structuring. The server does not need to connect to the database to verify the validity of the message. The payload can be customized for your application
  • Cross-domain authentication is supported for single sign-on (SSO).

Single sign-on: In multiple applications, users need only log in once to access all trusted applications.

WHY JWT

In addition to the advantages mentioned above, JWT has the following advantages over traditional server-side authentication.

  • Fully relies on stateless apis, which conform to RESTful design principles
  • Easy to implement CDN, static resources distributed management
  • Authentication is decoupled, no specific authentication scheme is required, and tokens can be generated anywhere
  • Supports native mobile apps over Cookies
  1. So the first thing about states is let’s look at what a state is, what is stateless and what is stateless.

State: the state of the request is in the process of the client and server interaction, preserved the relevant information, the client is saved in the page/request/session/application or global scope, and server generally exist in the session.

Stateful API: The server holds the client’s request status. The server will use the sessionID passed by the client to retrieve the previous interaction information in its session scope and respond.

Stateless APIS: Statelessness is a key principle of RESTful architectural design. Each request of stateless API is independent. It requires the client to save all required authentication information, and submit data containing cookies and other states in the form of URL for each request.

JWT is a good example of the statelessness principle. After the user logs in, the server returns him a token, which he saves locally. After that, all subsequent access to the server requires this string of JWT to gain access to server-related routes, services, and resources. JWT, for example, has been widely used for single sign-on because of its small size and simple handling (using HTTP headers with Bearer attributes + tokens) to support cross-domain operations.

  1. Distributed management In traditional session authentication, the server must save the session ID for authentication with the cookie sent by the user. At the beginning, the session ID is saved on only one server. Therefore, only one server can answer the session ID, even if other servers are idle. Therefore, the advantages of distributed servers are not taken advantage of. However, JWT relies on the local storage of authentication information on the client and does not need to use the information stored on the server for verification, so any server can respond and the resources of the server are well utilized.

  2. Verification decoupling As long as you have the authentication information needed to generate tokens, the token generation interface can be called anywhere without tedious coupled authentication operations. It can be described as a one-time generation and permanent use.

  3. Native app support (I don’t know much about mobile development) Native mobile apps don’t support cookies and sessions very well, but the token approach is better.

In addition, JWT’s solid, structured standards are another reason we chose it. Especially when developing with NodeJS, well, node is great!

A process in which a client interacts with a server using JWT

First, a client with an account on a website sends a POST request login with its own account password. Since this is the first contact, the server will verify whether the account and password are valid. If they are consistent, a token will be generated according to the key and returned. The client receives the token and stores it in the localStorage. After that, when you need to access a protected route or resource, the server checks to see if the token you have stored locally is still valid as long as it is attached (usually with Bearer attributes placed in Header Authorization attributes). And whether the check information is correct, and then make the corresponding response.

// Header
{
  "alg": "HS256",
  "type": "JWT"
}
// Payload
{
  // reserved claims
  "iss": "a.com",
  "exp": "1d",
  // public claims
  "http://a.com": true,
  // private claims
  "company": "A",
  "awesome": true
}
// $Signature
HS256(Base64(Header) + "." + Base64(Payload), secretKey)
JWT = {Base64(Header), Base64(Payload), $Signature}
Copy the code

The first part is the Header. First declare a JSON object with a type attribute of JWT and an ALG attribute of HS256, indicating that the final encryption algorithm used is HS256.

The second part is Payload Claim. This part is defined as the state of the entity. Just like the token itself attached metadata, the claim contains the information we want to transmit and the information used for server validation. It is generally divided into three categories: reserved/public/private.

The third part is Signature. It consists of the HS256 encryption algorithm specified in the Header. The first parameter is the encoded Header and the encoded Payload. The string after the connection, the second argument being the generated key, is saved by the server. Each time the server receives the token, it decrypts the user information and key used for authentication and compares them with the saved key to verify the user’s identity.

I am so tired after writing such a long article… Also want to continue to dig JWT specific application, how to verify the server, JWT use cookies or HTML5 Web Storage good, the rest can only stay in the next decomposition.

Thanks for the following reference articles: Json Web Token Introduction Json Web Token Introduction in-depth RESTful stateless principles