Original link:
http://blog.csdn.net/liuwenbiao1203/article/details/52351772
The traditional cookie-session mechanism can guarantee the security of the interface. If the authentication is not passed, it will jump to the login interface or the call fails.
Under today's RESTful API interface, cookie-session can no longer play a good role in protecting your API.
In more forms of Token-based verification mechanisms, JWT is essentially a Token , but it is slightly different.
What is JWT?
JWT in time JSON Web Token, which is a form of compact and self-contained JSON data that is delivered in various systems based on RFC 7519.
Compact: Due to the small size of the transmitted data, JWT can be passed through GET, POST and placed in the HTTP header, and also because it is small, it can be transmitted faster.
Self-contained: The payload can contain user information to avoid database queries.
JSON Web Token consists of three parts, separated by .:
Header
Payload
Signature
A JWT looks like this in form:
xxxxx.yyyy.zzzz
Header generally consists of two parts:
alg
type
alg is the hash algorithm used such as HMAC SHA256 or RSA, and typ is the type of Token, which is naturally 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 the JWT, which contains many kinds of claims.
The entity of Claims generally contains the user and some metadata. These claims are divided into three types: reserved, public, and private claims.
(Reserved claims) reserved claims: some predefined claims, 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 keep the JWT compact
(Public claims) public claims : This part can be freely defined, but be careful to conflict with IANA JSON Web Token.
(private claims) private claims : This part is a custom part of shared identified information.
A Pyload can look like this:
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
This part is also encoded into the second part using Base64Url.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.<third part>
Signature
When creating this part, you should already have the encoded Header and Payload. You also need a secret key, and the encryption algorithm should be specified in the Header.
An example using HMAC SHA256 is as follows:
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
This signature is used to verify the sender's JWT and also to ensure that it has not been tampered with during the period.
So, your full JWT should look like this:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
Note: The three parts separated by .
Workflow of JSON Web Token
When the user logs in with a certificate or account password, a JSON Web Token will be returned. At the same time, the JWT can be stored in local storage or in a cookie to replace the traditional server-side creation of a session to return a cookie.
When users want to use protected routes, they should bring JWT with the request. Generally, the form of Bearer is used in the Authorization of the header. The Authorization of a request header containing JWT is as follows:
Authorization: Bearer <token>
This is a stateless authentication mechanism. The user's state never exists on the server side. When accessing a protected route, the Authorization JWT in the HTTP header will be verified. At the same time, the JWT will bring some necessary information, no need Query the database multiple times.
This stateless operation can fully use data APIs, even on downstream services. These APIs have nothing to do with which server. Therefore, since there is no cookie, there is no cross-domain (CORS, Cross-Origin). Resource Sharing).