This is the 30th day of my participation in the Wenwen Challenge

HTTP itself is a stateless protocol, which means that if a user provides a user name and password to authenticate the user, the user has to authenticate the user again on the next request, because HTTP does not know which user made the request. So, in order to make our application which is able to identify the user request, we can only on the server information of a user login, the login information will be in response to the browser, tell save it for a cookie, so that next time the request is sent to our application, so that we can identify the request of the application of from which the user, This is traditional Session-based authentication.

However, session-based authentication makes it difficult to expand the application itself. With the increase of different client users, the independent server can no longer bear more users, and the problems of session-based authentication applications will be exposed.

The introduction of JWT

JWT, as an open standard, is either compact (fast, small) or self-contained (self-contained, payload will contain all the information the user needs, avoiding multiple queries to the database). Defines secure JSON objects for sending between parties.

The reason for introducing JWT is that JWT serves well as a carrier between access tokens and Refresh tokens, which is a good way to securely transfer information between two sides of the Web. When only the authorized server holds the secret that issues and verifies the JWT, then only the authorized server can verify the validity of the JWT and send the JWT with the signature, which only guarantees the validity and security of the TOKEN based on the JWT.

The composition of JWT

The JWT format is generally as follows:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiY2FuZyB3dSIsImV4cCI6MTUxODA1MTE1NywidXNlcklkIjoiMTIzNDU2In0.IV4XZ0y0nMp mMX9orv0gqsEMOxXXNQOE680CKkkPQcs

It consists of three parts, each of which passes. Separately, they are:

  • The Header in the head
  • Payload
  • Signature Signature

Then we will introduce each part in detail.

Header

The head usually consists of two parts:

  • Typ, usually JWT.
  • Alg encryption algorithm, usually HMAC SHA256 or RSA.

A simple header example is as follows:

{
	"alg": "HS256"
	"typ": "JWT"
}
Copy the code

This part of the JSON is then Base64Url encoded to form the first part of the JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Playload

The payload, the second part of JWT, is the vehicle used to carry valid information, mainly declarations about user entities and additional metadata. It consists of three parts:

  • Registered Claims, which is a set of intended but not mandatory claims that provide a useful set of claims that can be used together. There are iss(JWT issuer), EXP (JWT expiration time), sub(JWT user), AUD (JWT recipient), etc.
  • Public claims can include any information, such as user information or business expansion information.
  • A claim defined by both a JWT provider and a consumer that is neither a registration statement nor a public statement.

You are not advised to add sensitive information to the payload because Base64 is decrypted symmetrically, which means that the information in the payload is visible.

A simple payload example:

{
 	"name": "cang wu"."exp": 1518051157."userId": "123456"
}
Copy the code

This part of the JSON will be Base64Url encoded to form the second part of the JWT:

eyJuYW1lIjoiY2FuZyB3dSIsImV4cCI6MTUxODA1MTE1NywidXNlcklkIjoiMTIzNDU2In0

Signature

To create a signature, the encoded header, the encoded payload and a secret are required. Finally, the encryption algorithm ALG defined in the header is used to encrypt and generate the signature. The pseudo-code of the generated signature is as follows:


HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)
Copy the code

The encryption algorithm used is HMACSHA256

Secret is stored on the server to authenticate and issue the JWT, so it must be held only by the server and should not be disclosed.

Here’s a simple signature:

IV4XZ0y0nMpmMX9orv0gqsEMOxXXNQOE680CKkkPQcs

This will become part 3 of the JWT.

Finally, these three sections pass. Split to form the final JWT as follows:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiY2FuZyB3dSIsImV4cCI6MTUxODA1MTE1NywidXNlcklkIjoiMTIzNDU2In0.IV4XZ0y0nMp mMX9orv0gqsEMOxXXNQOE680CKkkPQcs

summary

Similar to HTTP, token-based authentication is stateless and does not need to retain user authentication information or session information on the server. This means that token-based applications do not need to consider which server users log in to, which facilitates application expansion.