JWT认证 - 爱码网

1 从个小问题开始

Json web token 是一种跨域认证解决方案。

判断一个用户是否已经授权登录有几种方式？

基于token的鉴权机制类似于http协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利。

流程上是这样的：

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

服务器不保存任何会话数据，即服务器变为无状态，使其更容易扩展。

JWT就是token机制的一种实现方式。

传统session机制没有分布式架构，无法支持横向扩展，不适用于服务器集群或者跨域体系结构。

每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以方便用户下次请求的鉴别，通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。

解决方案：通过客户端保存数据，而服务器根本不保存会话数据，每个请求都被发送回服务器。 JWT是这种解决方案的代表。

OAuth2.0是授权框架，描述了在各种不同场景下，多个应用之间的授权问题。

JWT是认证机制，基本思路就是用户提供用户名和密码给认证服务器，服务器验证用户提交信息信息的合法性；如果验证成功，会产生并返回一个Token（令牌），用户可以使用这个token访问服务器上受保护的资源。

两者可以结合使用。

JWTtoken如下格式，结构为header.payload.signature
JWT认证
它是一个很长的字符串，中间用点（.）分隔成三个部分。结构为header.payload.signature

Header 和 Payload 由原来的json格式字段Base64URL编码为前两部分，解码查看
JWT认证 Signature 部分是对前两部分的签名，防止数据篡改。

首先，需要指定一个**（secret）。这个**只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256）产生签名。

算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用"点"（.）分隔，就可以返回给用户

存在形式：一般是在请求头里加入Authorization，并加上Bearer标注

前面提到，Header 和 Payload 编码算法是 Base64URL。这个算法跟 Base64 算法基本类似，但有一些小的不同。

JWT 作为一个令牌（token），有些场合可能会放到 URL（比如 api.example.com/?token=xxx）。Base64 有三个字符+、/和=，在 URL 里面有特殊含义，所以要被替换掉：=被省略、+替换成-，/替换成_ 。这就是 Base64URL 算法。

JWT的安全性体现在signature部分，所以使用的加密算法和**是关键。

签署JWT的最常见算法是：

JWT默认使用 HS256

针对较短**的HS256加密目前已有**方法。 https://github.com/brendan-rius/c-jwt-cracker

所以在使用上应设置强度较大的**，HS256至少选择256位以上的**长度（1字符=8位），推荐使用更安全的加密方式，例如 非对称加密 RS256

JWT不负责传输安全,传输过程中需加密或者https。

前面提到JWT的格式，前两部分Header和Payload是Base64URL编码，是客户端可解密的部分，因此不应该在JWT的Payload部分存放敏感信息。

JWT的最大缺点是服务器不保存会话状态，所以在使用期间不可能取消令牌或更改令牌的权限。也就是说，一旦JWT签发，在有效期内将会一直有效。

JWT本身包含认证信息，因此一旦信息泄露，任何人都可以获得令牌的所有权限。为了减少盗用，JWT的有效期不宜设置太长。对于某些重要操作，用户在使用时应该每次都进行进行身份验证。

参考：
http://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html

https://www.sjoerdlangkemper.nl/2016/09/28/attacking-jwt-authentication/