JSON Web Token(JWT)

When validating a JWT the following steps MUST be taken. If any of the listed steps fails then the token MUST be rejected for processing.

1. The JWT MUST contain exactly two period characters.
2. The JWT MUST be split on the two period characters resulting in three strings.The first string is theEncoded JWT Header;the second is the JWT Second Part;the third is the JWT Third Part.
3. The Encoded JWT Header MUST be successfully base64url decodedfollowing the restriction given in this specification thatno padding characters have been used.
4. The JWT Header MUST be completely valid JSON syntax conforming to RFC 4627 [RFC4627].
5. The JWT Header MUST be validated to only include parametersand values whose syntax and semantics are both understood and supported.
6. Determine whether the JWT is signed, encrypted, or plaintextby examining the alg (algorithm) header value and optionally,theenc (encryption method) header value,if present.
7. Depending upon whether the JWT signed, encrypted, or plaintext, there are three cases:
   • If the JWT is signed, all steps specified in [JWS] for validating a JWS MUST be followed.Let the Message be the result of base64url decoding the JWS Payload.
   • If the JWT is encrypted, all steps specified in [JWE] for validating a JWE MUST be followed.Let the Message be the JWE Plaintext.
   • Else,if the JWT is plaintext,let the Message be the result of base64url decoding the JWE Second Part.The Third Part MUST be verified to be the empty string.
8. If the JWT Header contains a typ value of either “JWS” or “JWE”, then the Message contains a JWT that was the subject of nested signing or encryption operations, respectively. In this case, return to Step 1, using the Message as the JWT.
9. Otherwise, let the JWT Claims object be the Message.
10. The JWT Claims Object MUST be completely valid JSON syntax conforming to RFC 4627 [RFC4627].
11. When used in a security-related context,the JWT Claims Object MUST be validated to only include claims whose syntax and semantics are both understood and supported.

session认证:

客户端发送请求-服务器存储一份用户登陆的信息-响应时传给浏览器（cookie）

下次请求时发送给应用--应用可以识别请求来自那个用户。

1. 应用每次都给服务器cookie，造成服务器的压力

2. cookie被截获，用户会受到攻击

3. 分布式受限

token的鉴权机制：

用户使用用户名密码请求-服务器验证发送给用户一个token-客户端存储token并且每次请求附上token-服务端验证token返回数据

这个token必须要在每次请求时传递给服务端，它应该保存在请求头里， 另外，服务端要支持CORS(跨来源资源共享)策略，一般我们在服务端这么做就可以了Access-Control-Allow-Origin: *。

JWT的构成

第一部分我们称它为头部（header),第二部分我们称其为载荷（payload, 类似于飞机上承载的物品)，第三部分是签证（signature).

原网址：https://www.jianshu.com/p/576dbf44b2ae

ＨＴＴＰ常用请求方法：

ｇｅｔ：将参数直接拼在ｕｒｌ中

ｐｏｓｔ：将参数转成二进制数据放入ｂｏｄｙ中

ｈｅａｄ

ｐｕｔ将参数转成二进制数据放入ｂｏｄｙ中

ｄｅｌｅｔｅ将参数直接拼在ｕｒｌ中

分布式：一个业务拆分成多个子业务，部署在不同的服务器上

集群：同一个业务，部署在多个服务器上