哈喽小伙伴们大家好！作为一名，程序🦍，尤其是一名后端程序🦍，为了确保系统的安全，权限校验是我们在日常开发中必须要注意的一个模块，那说到权限校验，大家都用过哪些框架或者技术呢？你为什么要在众多的技术中选择这个技术而不是其他的？我们怎么去衡量应该选择哪个技术？今天，我们通过JWT 这样一个权限校验的框架，来详细聊聊这事儿。
所谓JWT（JSON Web Token），它其实是一种基于 JSON 的开放标准（RFC 7519），用于在网络应用间安全传递声明。它通过数字签名确保传输信息的完整性，通常由三部分组成：头部（Header）、载荷（Payload）和签名（Signature）。说白了，就是一个权限校验的框架。
既然它能校验权限，那它是怎么校验的呢？
首先，这是涉及到一个JWT的创建。
用户在登录的时候，服务器验证凭证后创建 JWT
这里的Token 包含三部分：Header（令牌类型、签名算法）、Payload（用户 ID、角色、权限声明等）、和Signature（使用密钥签名）
创建好之后要把这个token发给客户端，也就是浏览器（相当于你跟我交流，我得先知道你是谁吧），客户端接收到这个Token 后，要把它存储在本地（如 LocalStorage/Cookie）
这里考查大家一个问题，客户端还有哪些存储数据的方法？
存好之后，后续请求需要在 HTTP Header 中带上这个token：<span leaf=""><span textstyle="">Authorization: Bearer <token></span></span>
接下来，就要进行权限校验啦，主要过程分为以下几步：
首先是签名验证：在这里，服务器使用相同密钥验证 Token 的完整性，防止被恶意篡改；
这里我提一个 HTTPS 的概念，大家想一想我为什么要在这里提这个概念？
除了验证完整性之外，时效性是不是也需要验证一下，我们不能使用过期的数据呀，这里主要检查 <span leaf=""><span textstyle="">exp</span></span>（过期时间）和 <span leaf=""><span textstyle="">nbf</span></span>（生效时间）；
如果上述两个条件都满足，我们就需要看一下用户是不是具备当前数据的操作权限，怎么判断呢？需要从 Payload 中解析用户角色或权限声明（例如这个字段：<span leaf=""><span textstyle="">roles: ["admin"]</span></span>）；
一般情况下，用户对资源的访问情况的限制主要分为以下两种：
1）、基于角色（RBAC）：如管理员可访问所有接口
2）、基于权限（ABAC）：如用户需有 <span leaf=""><span textstyle="">create_post</span></span>权限才能发布文章
好了，看了上面的内容，其实并没有多难，那面试官可能就接着问了，JWT 和其他的框架相比，有什么优点和缺点？
这里为了更加清晰的对比，我们来看这张表格
首先，JWT是无状态的，它不需要在服务器端存储会话的信息，而传统的session需要在客户端存储会话状态；
其次，JWT天生支持跨域，可以通过 HTTP Header 进行传递，适合这种前后端分离的系统；而传统的 Cookie/Session 由于受到同源策略的限制，需要额外的成本来处理跨域。
那接下来，肯定也是大家比较关注的一个问题，它的性能
在性能方面，JWT在验证的时候只需要解密和签名验证，无需数据库查询，开销较小，而传统方案可能需要频繁查询数据库或缓存。
以上只是它的优点，但是它有没有缺点呢？肯定是有的。
大家应该听说过一句话，牺牲空间来换时间。对，如果大家看到过token的话，你会发现它其实就是一个字符串，但是这个字符串可不是三个五个字母啊，它可是存了用户完整的信息啊，如果过长的话，来来回回传递是不是就造成了较大的网络开销？
除此之外呢，这个token它一旦生成就不能再变了啊，那如果用户的权限发生变化的时候，我们是不是需要重新生成一个token，是不是又增加了性能的开销？
接下来，是一个老生常谈的话题，大家都知道，我们的浏览器的 cookie,它的存储容量是不是有限的（提问，具体是多少？，为什么只有这么点？），那如果token过大的话是不是就存不了了？那这时候，我们只能被迫使用localstorage,它安全吗？会存在哪些问题？这里由于篇幅原因，我们这期文章不展开讲。
好啦，以上就是本期文章的全部内容，感谢大家的阅读，我们下期再见哦\~
文章转载：什么是JWT？ 它是怎么做权限校验的？
发表评论