BearerToken introduction of JWT

Bearer certification

Provides a standard HTTP authentication framework: the server can be used to send a challenge (challenge), the client provides authentication credentials for the client request according to the challenge. Question with workflow response is as follows: the server returns to the client 401 (Unauthorized, unauthorized) status code, and how to add the authentication information in the WWW-Authenticate header, which includes at least a challenge-way. The client can then add an Authorization header in the request to verify that the Value for the authentication credential information.

In the standard HTTP authentication schemes, we are more familiar with "Basic" and "Digest", the former name of the user password as authentication credentials using BASE64 encoding, which is an upgraded version of Basic, more secure, because Basic is transmitted in clear text passwords information is encrypted and transmitted Digest. Cookie authentication foregoing description belonging Form authentication, not part of the standard HTTP authentication.

Bearer verification article to introduce the standards also belong to the HTTP protocol validation, it became popular with the OAuth protocol, as defined in detail: 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

Bearer credential verification referred BEARER_TOKEN, or the access_token, its issuance and verification controlled entirely by our own application, without depending on the system and Web server, Bearer request verification criteria as follows:

Authorization: Bearer [BEARER_TOKEN] 

JWT(JSON WEB TOKEN)

Bearer certification described above, the core is BEARER_TOKEN, and the most popular Token encoding is: JSON WEB TOKEN.

Json web token (JWT), is a statement in order to pass between the network application execution environment JSON-based open standard [RFC 7519 ( https://tools.ietf.org/html/rfc7519 ). The token is designed to be compact and safe, especially for distributed sites of single sign-on (SSO) scenarios. JWT's statement is generally used between identity providers and service providers to deliver the authenticated user identity information in order to obtain resources from the server, you can also add some additional business logic other necessary information statement, the token also may be directly used for authentication may be encrypted.
jwt consists of three main elements:

1. Head Header
2. Load Payload
3. Signature Signature

Jwt Token comprising use. Partition three sections

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

Head Header

Header generally consists of two parts:

1. Alg
2. type

alg is the hash algorithm is used, such as: HMAC SHA256 or RSA, typ is the Token type, this is: JWT.

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

Base64Url then encoded into a first portion

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.<second part>.<third part>

Load Payload

This section is the main JWT information storage section, which contains many statements (claims).

Claims entity generally comprises a number of users and metadata, which claims classified into three types:

1. reserved claims: some declarations predefined, not mandatory but recommended they include iss (issuer), exp (expiration time), sub (subject), aud (audience) and other (here using the three-letter reason is to ensure that JWT compact).
2. public claims: public statement, this section can be easily defined, but be careful and IANA JSON Web Token conflict.
3. private claims: Private statement, this part is a shared part of the information is identified in the custom.

A simple Pyload can be 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 also used to encode a second portion Base64Url

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.<third part>

Signature Signature

Signature verification is used while the sender JWT also ensured not been tampered with during.

header and payload after use Base64 encoding and a secret key, use the header specified signature algorithm signature.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Therefore, the use of JWT has the following benefits:

1. General: Because of the versatility of json, so JWT can be cross-language support, like JAVA, JavaScript, NodeJS, PHP and many other languages ​​can be used.
2. Compact: JWT configuration is very simple, small occupied bytes may be placed by the HTTP header GET, POST, etc., are very easy to transport.
3. Extended: JWT self-indulgence, contains all the information necessary, do not need to save the session information on the server side, the expansion is very easy to use.