jwt生成的token,应该存在哪里?
答:通常存储在客户端里。
jwt 即 JSON Web Token,是一种认证协议,一般用来校验请求的身份信息和身份权限。
早上逛某乎的时候,遇到一位同学在问这个问题,很好奇jwt的存储位置。刚好前段时间在学习此内容,不请自邀,厚颜强答。
最开始我也很好奇这个token怎么保存,还差点想搞个redis存储这个token。
后来查阅资料才知道,原来这个token,服务端是可以不保存的。只需要客户端保存好就行,无论什么保持方式,甚至你让用户写纸条揣兜里都可以!
那这个token是怎么工作的呢?
先来说说需要服务端存储的操作,即传统的session会话的做法。
首先要做用户登陆,先要在服务端维护一个登陆表,这个登陆表可以放在缓存里,也可以放进数据库里。
当用户登陆的时候,把用户信息写入这个登陆表,然后导出一个登陆id,也就是所谓的session,把这个session返回给客户的,让客户端下次请求把这个信息带上来。
对于前端的小伙伴来说,这个过程通常无感知,后端的老哥们使用一个叫
set-cookie
的http头字段,自己把数据写入浏览器cookie里了。然后请求的时候,浏览器又会自己把cookie写进请求头里面。
当客户端请求进入服务端时,服务端拿到cookie里面的session,然后到登陆表里面去查用户信息,校验用户权限,然后即可完成正常的业务交互。
诶,那现在我因为各种乱七八糟的原因,不想维护一个登录表了,想想要怎么搞?
简单呀,直接把用户信息发给客户端,让客户端每次把用户信息都带过来,这样请求一进来,连表都不用查,直接就知道是哪个用户在请求。
但是这样子,用户的信息都曝光了,那些中间人呀,最喜欢这种耿直请求了,他们直接拿个凳子坐在你服务器端口,坐个几天,你数据库里的全家老表就被别人扒个清清楚楚。
这样肯定不行,那怎么办?
加个密再混个淆呗,这样老哥们拿到你的token,一时半会也一脸懵逼,大概率会大大咧咧地走了,只留下少部分有备(KPI)而来的老哥在苦苦寻求破解。
而你在服务端一解密,你就拿到用户信息了,同样的,你把过期时间也写进密文里面,遇到过期就401跳登录页。这样,一个不需要后端存储登录凭证的方案就出炉咯。
这就是jwt最基本的工作原理:就是把身份信息交给客户端保管。
jwt生成的token由header、payload、signature三部分组成,这三个部分用小数点“.”分隔开。
- header,也就是头部信息,是描述这个token基本信息,是一个json格式:
{ "alg":"HS256", "typ":"JWT" }
alg
代表的是后面signature签名部分的生成加密算法,typ
表示该token是jwt类型。 - payload,就是你的那些用户数据啦,也是一个json格式。不过jwt不建议将敏感数据放进里面,因为规范里,payload和header一样,仅仅只是做一次base64编码后显示在token上。
- signature,是这个token的签名,通常情况下是将前面的header和payload加上一个你自己定义的私钥字符串一起加密生成的字符串。
因为前面说了,jwt仅仅是将payload的内容做一次base64编码,所以那些攻击者老哥要改你的内容还是很简单的,但是老哥们不知道你的私钥啊,改了之后没法生成正确的签名,用加密的方式再次对请求进来的header.payload进行校验,发现跟signature对不上,这时候你就可以很清楚知道,有人在搞事情,直接返回个500假装服务器挂了。
如果想更安全,建议全程使用https协议进行请求通信。
当然,你已经了解了这个工作原理,自己搞一套恶心人的规范,也不是不行,比如,把payload再加一次密然后gzip下等等。
那,采用jwt的好处都有啥?
第一点,自然是服务端不需要维护一个登陆表了,节省空间,特别是用户多的情况。
第二点,拓展简单,前提是你不搞事情,老老实实遵守采用json格式去表述你的内容。
第三点,无状态,只要服务端支持解析,就可以开展业务,不需要专门搞个机制去共享session,方便加机子。
第四点,支持各种各样的客户端,不支持cookie也能玩。
坏处嘛,自然就是每次请求都要把这些数据带来带去的,肯定是增加了请求内容的。而且,每次请求进来你都要去校验,去拿header和paylaod加一次密与signature校验,也会增加请求的处理时间。这个与传统操作相比,其实是一个时间与空间之间的权衡问题,最后,还是看你选择咯。
上一篇: 生成Vue带有二维码的分享海报
下一篇: 无法连接数码网络2022
推荐阅读
-
iCloud 切换区域,中国区保留 appStore(更新)--自 2018 年 2 月 28 日起,中国区 iCloud 由云上贵州管理 苹果公司发布的公告 https://support.apple.com/zh-cn/HT208352 关键词 关键部分 受影响的 iCloud 账户:国家或地区设置为 "中国 "的 Apple ID。 iCloud 包含的服务照片、邮件、通讯录、日历、提醒事项、备忘、书签、钱包、钥匙串、云备份、云驱动器、应用程序数据 新条款和条件: 同意仅出于本协议允许的目的并在中国法律允许的范围内使用服务。 云桂洲在提供服务时应使用合理的技能并尽职尽责,但在适用法律允许的最大范围内,我们不保证或担保您通过本服务存储或访问的任何内容不会意外损坏、崩溃、丢失或根据本协议的条款被删除,如果发生此类损坏、崩溃、丢失或删除,我们不承担任何责任。您应自行负责维护您的信息和数据的适当备份。 Apple 和云上贵州有权访问您存储在服务中的所有数据,包括有权根据适用法律相互之间共享、交换和披露所有用户数据(包括内容)。 本协议的解释、效力和履行应适用*法律。对于因本协议引起的或与本协议有关的任何争议,云桂洲和您同意提交中国国际经济贸易仲裁委员会(CIETAC)根据提交仲裁时有效的法律在北京进行具有约束力的仲裁。 由云桂洲管理,用户选择: 停用; ID 到地区; 受 iCloud(由云桂洲运营)条款和条件约束 首先,我想说说我对数据安全的看法。 当我在朋友圈发布通知时,有些朋友回复说国外的操作并没有多安全,或者国外的安全只是相对于国外而言的等等。首先,我非常感谢这些朋友,这让我反思什么是数据安全。以下观点均属个人观点: 国外的月亮一定比国内圆? 这是一个根深蒂固的问题,只要有人说国外的东西比国内好,就会有人嘲笑崇洋媚外。我觉得我们在某些方面应该向国外学习,比如搜索引擎和版权问题。打开百度搜索 "数据安全",第一行肯定是广告。打开谷歌搜索 "数据安全",第一条就是 "数据安全_百度百科" .....各种版权问题大家都明白,支持正版,但不仅客户一心想找免费破解,就连作者也往往没有保护自己劳动成果或产品的想法。但从另一个层面来说,国内的发展和安全,甩国外几条街。没有说哪里好,哪里不好,辩证地去学习更好。 国外也有别有用心的数据泄露,谈何安全? 从加密解密的角度看,自古以来就没有绝对安全的加密,只有相对安全的做法。苹果的棱镜门、微软的 cpu 漏洞,各种参差不齐的被破解案例 ....是的,这的确是一个很好的论据,但凡事都不能只看一面,当年苹果面对FBI破解手机的要求,几经论证,苹果还是拒绝破解。这点拿到国内,只要上面的文件传达下去,还有企业敢说不吗?还敢说不吗? 关于这次iCloud数据迁移个人看法? 把数据迁移到贵州的云端,相当于把手机的所有数据都存储在贵州的云端服务器上。也许访问数据的速度会快很多,但我会把我的iCloud区放到美国,因为我不想数据存在云上贵州后经常接到莫名其妙的电话或短信,更不想因为乱用国外服务器而被请去喝茶。iCloud一个ID,即从中国账号转到美国区,主要用于数据存在美国服务器上。appStore一个ID,除了注册一个中国ID外,专门用来下载应用用,因为国外ID不支持酷狗和网易云等应用。麻烦的是,用了新的 appStore ID 后,当前的应用还得重新下载安装,因为旧的应用 ID 与新的应用 ID 不兼容,安装不了。最后,iCloud迁移后,国内用户使用美国服务器,估计要 "扶墙 "了。 专业步骤: 首先,进行appleID设置,这是前提条件,否则无法选择转移区域! 取消 appleID 的双重认证 取消家庭共享选项 二、窗口下载并安装 icloud 3.0 版
-
JWT库生成Token的使用和背后的原理解析
-
区别jjwt生成的jwt token的不同版本
-
JJWT使用笔记(一)—— JWT token的生成
-
jwt生成的token,应该存在哪里?