1. 用户认证
Json web token 即JWT，一般用于实现用户登录认证，下面我们来区分一下传统的session认证和基于token的认证的区别。
- 基于session的认证
http协议是一种无状态的协议（每次请求无法保持用户登录状态），如果用户已经提供了用户名和密码认证过，那么下一次请求时，用户还要再一次进行用户认证才行，因为根据http协议，我们并不能知道是哪个用户发出的请求。因此，为了让我们的应用能识别是哪个用户发出的请求，我们只能在服务器存储一份用户登录的信息，这份登录信息会在响应时传递给浏览器，告诉其保存为cookie，以便下次请求时发送给我们的应用，这样我们的应用就能识别请求来自哪个用户了，这就是传统的基于session认证。
这种基于session的认证难以扩展，尤其是用户量增加时，基于session认证应用的问题就会暴露出来：
Session：每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以方便用户下次请求的鉴别，通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。
扩展性：用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。
CSRF：因为是基于cookie来进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。
- 基于token的认证
基于token的鉴权机制类似于http协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利。
认证流程如下：
1.用户使用用户名密码来请求服务器；
2.服务器进行验证用户的信息；
3.服务器通过验证发送给用户一个token；
4.客户端存储token，并在每次请求时附送上这个token值；
5.服务端验证token值，并返回数据；
这个token必须要在每次请求时传递给服务端，它应该保存在请求头里， 另外，服务端要支持CORS(跨来源资源共享)策略，一般我们在服务端这么做就可以了Access-Control-Allow-Origin: *。
2. JWT的结构
JWT是由三段信息构成的，将这三段信息文本用.链接一起就构成了Jwt字符串:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
它由三部分组成：头部（header)、载荷（payload)，签证（signature)。
- header
jwt的头部包含两个字段：
声明类型，这里是jwt
声明加密的算法 通常直接使用 HMAC SHA256
完整的header是下面这样的Json：
{
"typ": "JWT",
"alg": "HS256"
}
然后将header进行base64加密（该加密是可以对称解密的)，得到了JWT的第一部分：
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
- playload
载荷用于存放有效信息：标准中注册的声明、公共的声明、私有的声明。
标准中注册的声明(建议但不强制使用) ：
iss: jwt签发者；
iat: jwt的签发时间；
aud: 接收jwt的一方；
sub: jwt所面向的用户；
nbf: 定义在什么时间之前，该jwt都是不可用的；
exp: jwt的过期时间，这个过期时间必须要大于签发时间；
jti: jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击。公共的声明：
公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端可解密.私有的声明：
私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。
定义一个payload:
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
然后将其base64加密，得到JWT的第二部分：
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9
- signature
这个 signature 需要 base64 加密后的 header 和 base64 加密后的 payload 使用 . 连接组成的字符串，然后通过header中声明的加密方式以secret为密钥，进行组合加密，然后就构成了jwt的第三部分：
encodedStr = base64UrlEncode(header) + "." + base64UrlEncode(payload);
signature = HMACSHA256(encodedStr, "secret");
//TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
将这三部分用.连接成一个字符串，即得到完整的JWT：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
注意：secret是保存在服务器端的，JWT的生成也在服务端，secret用来进行JWT签发和验证，它是服务端的一个私钥，在任何场景都不应该流露出去。一旦secret被获取，客户端是可以自我签发jwt了，会引发安全问题。
3. 如何应用
一般是在请求头里加入Authorization，并加上Bearer标注：
headers: {
"Authorization": "Bearer" + token
}
服务端会验证token，如果验证通过就会返回相应的资源。整个流程就是这样的:
4. 总结
- 使用 JWT 不需要在服务端保存会话信息，因此易于扩展；
- JWT 中的 payload 部分还可以存储一些额外的自定义的非敏感信息字段；
- JWT 的字符串内容为 Json 格式，是可以跨语言通用；
- JWT 结构简单、小巧，便于传输。
JWT 中的 payload 部分是可被解密的，不能存放敏感信息；
保护好 secret 密钥；
使用https协议。
网友评论