jwt's official website: jwt.io is available in various languages, providing online codecs (slow, direct Baidu search)

Golang implementation of jwt: https://gitee.com/yuxio/jwt-go.git https://gitee.com/yuxio/go-jose.git

jwt consists of 3 parts: header, payload and signature, which are transferred as follows: Introduction of JWT of BearerToken

Bearer certification

HTTP provides a standard authentication framework: the server can be used to send a challenge to the client's request, and the client provides authentication credentials based on the challenge. The workflow of challenge and response is as follows: the server returns a 401 (Unauthorized) status code to the client, and adds information on how to authenticate in the WWW-Authenticate header, which contains at least one challenge method. Then the client can add an Authorization header to the request for verification, and its Value is the credential information for authentication.

In the HTTP standard authentication scheme, we are more familiar with "Basic" and "Digest". The former uses the BASE64 encoding of the user name and password as authentication credentials, and the latter is an upgraded version of Basic, which is more secure because Basic is a clear text transmission password Information, while Digest is transmitted after encryption. Cookie authentication introduced in the previous section is Form authentication, not HTTP standard authentication.

The Bearer authentication to be introduced in this article also belongs to the HTTP protocol standard authentication, and it has become popular with the OAuth protocol. For detailed definitions, see: RFC 6570 .


     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     | |<-(B)-- Authorization Grant ---| | | | +---------------+ | | | | +---------------+ | |--(C)-- Authorization Grant -->| Authorization | | Client | | Server | | |<-(D)----- Access Token -------| | | | +---------------+ | | | | +---------------+ | |--(E)----- Access Token ------>| Resource | | | | Server | | |<-(F)--- Protected Resource ---| | +--------+ +---------------+ Figure 1: Abstract Protocol Flow

The credential in Bearer authentication is called BEAER_TOKEN, or access_token, and its issuance and authentication are completely controlled by our own applications, without relying on the system and Web server. The standard request method for Bearer authentication is as follows:

Authorization: Bearer [BEARER_TOKEN]

JWT(JSON WEB TOKEN)

The core of Bearer authentication introduced above is Bearer_Token, and the most popular Token encoding method is: JSON WEB TOKEN.

Json web token (JWT) is an open JSON-based standard that is implemented to transfer declarations between web application environments [RFC 7519 ( https://tools.ietf.org/html/rfc7519 ). The token is designed to be compact and secure, and is particularly suitable for single sign-on (SSO) scenarios at distributed sites. The JWT statement is generally used to pass the authenticated user identity information between the identity provider and the service provider, so as to obtain resources from the resource server, and can also add some additional statement information necessary for other business logic. The token also Can be used directly for authentication or can be encrypted.
jwt mainly contains the following three contents:

Header
Payload
Signature

Jwt Token contains three parts used. Separated

{Header 头部}.{Payload 负载}.{Signature 签名}

Header generally consists of two parts:

alg
type

alg is the hash algorithm used, such as: HMAC SHA256 or RSA, typ is the type of token, in this case: JWT.

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

Then use Base64Url to encode into the first part

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.<second part>.<third part>

Payload

This part is the main information storage part of JWT, which contains many kinds of claims.

Claims entities generally contain users and some metadata. These claims are divided into three types:

reserved claims: some pre-defined claims are not mandatory but recommended, they include iss (issuer), exp (expiration time), sub (subject), aud (audience), etc. (the reason for using three letters here is to guarantee JWT compact).
public claims: Public claims, this part can be freely defined, but pay attention to conflict with IANA JSON Web Token.
private claims: Private claims, this part is a custom part of sharing the identified information.

A simple Pyload can look like this:

{
   "user_name": "admin", 
   "scope": [
       "read","write","del" ], "organization": "admin", "exp": 1531975621, "authorities": [ "ADMIN" ], "jti": "23408d38-8cdc-4460-beac-24c76dc7629a", "client_id": "webapp" }

This part is also encoded into the second part using Base64Url

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.<third part>

Signature

Signature is used to verify the sender's JWT while also ensuring that it is not tampered with during the period.

The signature hash part is to sign the above two parts of data, and generate a hash through the specified algorithm to ensure that the data will not be tampered with.
First, you need to specify a password. The password is only stored in the server and cannot be disclosed to the user. Then, use the signature algorithm specified in the header (HMAC SHA256 by default) to generate a signature according to the following formula.

Use Base64 encoded header and payload and a secret key, and use the signature algorithm specified in the header to sign.

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

result

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

base64UrlEncode

As mentioned earlier, Base64URL is used in both JWT header and payload serialization algorithms. This algorithm is similar to the common Base64 algorithm, with a slight difference.
The JWT as a token can be placed in the URL (eg api.example /? Token = xxx). The three characters used in Base64 are "+", "/" and "=". Because of the special meaning in the URL, they have been replaced in Base64URL: "=" removed, "+" is replaced with "-" , "/" Is replaced with "_", this is the Base64URL algorithm, it is very simple.

The working process of JWT

The client receives the JWT returned by the server and stores it in a Cookie or localStorage.

After that, the client will bring JWT in the interaction with the server. If it is stored in a cookie, it can be automatically sent, but it will not cross domain, so it is generally put in the Header Authorization field of the HTTP request.

Authorization: Bearer JWT_TOKEN

When crossing domains, JWT can also be placed in the data body of the POST request.

Using JWT has the following benefits

Universal: Because of the universality of json, JWT can be supported across languages, such as JAVA, JavaScript, NodeJS, PHP and many other languages.
Compact: The structure of JWT is very simple, the byte occupation is very small, and can be placed in the HTTP header through GET, POST, etc., which is very convenient for transmission.
Extension: JWT is self-contained and contains all the necessary information. It does not need to save the session information on the server side, which is very easy to apply.

Introduction of JWT_Introduction of JWT to BearerToken