为了账号安全,请及时绑定邮箱和手机立即绑定

漫谈JWT

2018.07.09 17:32 3380浏览

很多童鞋在课程中会问到一些与JWT相关的内容,在这里算是给大家简单聊一聊,不过在这里要提前说一下,由于JWT在不同的人和不同的项目中使用的方式都会有一些区别,这里仅仅代表个人见解。

一、JWT简介【对于了解JWT的童鞋,可以直接跳到最后】

咱们就不弄那些乱七八糟的概念,就简单点说一下JWT是什么、有什么和能干什么

1、 JWT概念和作用

JWT全称为json web token,说白了是什么呢? 就仅仅只是一个字符串而已,例如:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiSm9obiBEb2UiLCJhZG1pbiI6dHJ1ZX0.OLvs36KmqB9cmsUrMpUutfhV52_iSz4bQMYJjkI_TLQ 这样。

O(∩_∩)O 是不是特别长,特别丑?没关系,现在给大家解释一下这个东东到底是什么

2、JWT组成【对于JWT有基本了解的人可以忽略这一部分】

JWT包含了三个主要部分: Header.Payload.Signature,以" . "来进行分割,以上式举例:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJuYW1lIjoiSm9obiBEb2UiLCJhZG1pbiI6dHJ1ZX0.
OLvs36KmqB9cmsUrMpUutfhV52_iSz4bQMYJjkI_TLQ

注意尾巴上的两个点哦。

2.1 Header作用

Header部分主要存储关于签名算法的信息,通常不包含两个部分:token类型和采用的加密算法,大致源内容如下:
{ "alg": "HS256", "typ": "JWT"} ,然后使用Base64Url编码组成了Header部分,结果大致如:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9。

2.2 Payload作用

Payload翻译过来就是负载嘛,就是装东西嘛对不对,所以这一部分其实是用来存储一些信息的,至于是什么信息呢,重点来了 ----> 无所谓,惊不惊喜,意不意外?

其实Payload是一个比较重要的部分,这个东西其实就是一个数据实体,俗称Claim,JWT并不强制使用,它默认这一部分数据为业务数据,是系统业务需要的数据,可有可无,可多可少。一般在不特殊修改的情况下,主要包含几个部分: iss(签发者),exp(过期时间戳), sub(面向的用户), aud(接收方), iat(签发时间),大致的源样式是这样:
{ "sub": "1234567890", "name": "John Doe", "admin": true},经过Base64Url 编码以后,会变成JWT的第二部分字符串:eyJuYW1lIjoiSm9obiBEb2UiLCJhZG1pbiI6dHJ1ZX0。

2.3 Signature作用

创建签名需要使用编码后的header和payload以及一个秘钥,组成的公式:编码后的header、编码后的payload、一个secret进行加密HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

以上就是JWT的几个主要组成部分。

3、JWT的主要作用

JWT最开始的初衷是为了实现授权和身份认证作用的,可以实现无状态、分布式的Web应用授权,大致实现的流程如下:

图片描述

图中内容可见,JWT的使用流程大致有几步:

1、客户端需要携带用户名/密码等可证明身份的内容去授权服务器获取JWT信息;

2、每次服务都携带该Token内容与Web服务器进行交互,由业务服务器来来验证Token是否是授权系统发放的有效Token,来验证当前业务是否请求是否合法。

注意:这里很多刚接触JWT的童鞋经常会问一个问题,是不是每次请求都申请一次Token,这里需要注意,如果不是对于安全性要求非常高的情况,不建议每次请求都申请,因为会增加业务耗时,大部分时候我个人喜欢在登陆时申请,然后使用JWT的过期时间或其他手段来保障JWT的有效性

后来随着JWT使用的场景的成熟,逐渐引申的意义也可以抵御跨站请求伪造攻击【就不解释这是什么了,可以百度一下】和签名验签的流程。

以下是福利环节,也是重点答疑环节。

a)如何保证JWT的安全呢?

注意,这里经常会有一个误区,JWT本身和安全没关系,它就仅仅只是一个字符串,使用它来做安全远不如类似于RSA2这样的非对称加密的形式来的实在,由于客户端的程序对用户几乎完全透明,验签的过程对于他们来讲也是透明的,所以安全性肯定不会靠这个来实现,如果实在怕JWT的被盗取,可以考虑在Payload部分加入一些客户端独有的非敏感信息,用于在服务端来进行核验,比如使用MAC-Message Authentication Code、或者公钥之类的等等; 或者干脆就把生效时间设置的短一些,也可以减少暴漏的风险。

b)要不要将用户信息存入Payload呢

其实是一个道理,由于JWT本身没有安全性可言,所以存储用户信息,尤其是敏感数据是一件很可怕的事情,建议不要存放这一类信息;而且将太多的信息存入Payload以后,就增加了网络传输以及签名和验签的复杂度,也会造成时间的浪费;

c)如果想上传视频,如何使用JWT进行签名呢

这件事要分两头说,JWT签名对我个人而言,并不是所有数据都要签名,因为会增加业务耗时和复杂度,所以我一般都是对一些敏感数据才会进行签名。基于以上基点,不难分析出这个问题的答案:
1、如果视频并不算敏感数据,那么自然就不存在签名问题
2、如果确实认为视频是敏感数据,可以通过nodejs之类的东东获取到上传文件的对象,然后进行操作,当然,这是一个非常复杂的工作,要有心理准备哦。
3、这个问题其实仅仅只是一个例子,所有类似的问题处理方法差不多,只要意识到什么数据应该签名,什么数据可以不签名,其他都是一些技术细节,这里就不讨论了。

欢迎关注课程《Tomcat+Memcached/Redis集群 构建高可用解决方案 》

点击查看更多内容

本文原创发布于慕课网 ,转载请注明出处,谢谢合作

24人点赞

若觉得本文不错,就分享一下吧!

评论

相关文章推荐

正在加载中
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消