jwt存储
① JWT与Session的比较
如今，越来越多的项目开始采用JWT作为认证授权机制，那么它和之前的Session究竟有什么区别呢？今天就让我们来了解一下。
JWT是什么
定义
特点
使用JWT来传输数据，实际上传输的是一个字符串，这个字符串就是所谓的json web token字符串。所以广义上，JWT是一个标准的名称；狭义上，JWT指的就是用来传递的那个token字符串。这个串有两个特点：
结构
它由三部分组成：header（头部）、payload（载荷）、signature（签名），以.进行分割。（这个字符串本来是只有一行的，此处分成3行，只是为了区分其结构）
和Session的区别
为什么我们要把JWT和Session做对比呢？因为我们主要在每一次请求的认证时会用JWT，在此之前我们都是用Session的。那这两者的区别在哪儿呢？
本身的含义
看了前面的介绍，我们发现JWT这个字符串其实本身就包含了关于用户的信息，比如用户名、权限、角色等。
Session传递的sessionId虽然是一个更简单的字符串，但它本身并没有任何含义。
所以一般说来JWT的字符串要比sessionId长，如果你在JWT中存储的信息越长，那么JWT本身也会越长。
而Cookie的存储容量是有限制的（通常为4KB），所以大家在使用的时候需要注意。
解析方法
JWT的header和payload其实是有json转变过来的，而signature其实就是一个加密后的字符串，因此解析起来较为简单，不需要其他辅助的内容。
sessionId是服务器存储的用户对象的标识，理论上需要一个额外的map才能找出当前用户的信息。
管理方法
JWT理论上用于无状态的请求，因此其用户管理也只是依赖本身而已。我们一般是在它的payload中加入过期时间，在不增加额外管理的情况下，它只有自动过期的方式。
Session因为它本就是存储在服务器端的，因此管理方案就有很多，而且大多都很成熟。
跨平台
JWT本身就是基于json的，因此它是比较容易跨平台的，可以从官网下载不同平台的包，解析即可。
session的跨平台可能就不那么好做了，需要考虑的地方在于用户信息存储的格式，ProtoBuf、json、xml等，管理的话可能就需要专门的统一登录平台，这个就不展开了。
时效性
无状态JWT一旦被生成，就不会再和服务端有任何瓜葛。一旦服务端中的相关数据更新，无状态JWT中存储的数据由于得不到更新，就变成了过期的数据。
session就不一样了，sessionId本身就没有太多含义，只需修改服务端中存储的数据即可。
适用场景
JWT
JWT的最佳用途是一次性授权Token，这种场景下的Token的特性如下：
真实场景的例子——文件托管服务，由两部分组成：
如何把JWT用在这个场景中呢？
Session
Session比较适用于Web应用的会话管理，其特点一般是：
总结
② Token存储方式JWT
JWT 由3个部分组成，用 . 分隔
JWT 通常看起来像下面一样
Header
例如：
Payload
例如：
Signature
下面例子使用 HMAC SHA256 算法进行签名
真正的 JWT 看起来像下面例子一样
JWT 主要依靠签名核心，也可自实现签名验证,主体信息存放。
cat index.js
官方已经提供很全的语言 例子
③ jwt的token怎么生存的
引入依赖包加密解密方法。
在生产环境中，一般jwt会保存用户的名字和角色权限等信息。可以将token写到cookie里，每次前端访问后台时，可以在拦截器或者过滤器取到token，然后解密，先判断是否过期，过期就抛异常阻止其访问。然后取出信息保存到threadLocal里，方便以后调用这些信息，当后台访问完成后，从thredLocal删除此用户信息。
服务器认证以后，生成一个JSON格式的对象返回给客户端。之后客户端与服务端通信的时候，都要发回这个JSON对象。服务器完全根据这个对象认证用户身份。
④ jwt密钥存在哪
jwt一般存在在sessionStorage、cookie或localStorage里。jwt即JSON Web Token，是一种认证协议，一般用来校验请求的身份信息和身份权限。
sessionStorage是会话级存储，关闭页面或浏览器后会被清除；
用cookie存储时需要注意防范CSRF攻击，前网页的URL要与请求目标一致；
用localStorage存储不易受到CSRF的影响，需要通过代码来实现，容易受到XSS攻击。
⑤ jwt原理是什么
GWT单点登录原理这是一个技术原始问题，服务器这边准备一个密码字符串，各服务器保持字符串一样。
当用户登录一台服务器成功后，服务器将他的账号和密码字符串通过算法整合一下，形成一个新的字符串。通常这个算法会将密码字符串用哈希的方式来处理，但账号可以直接在新的字符串中拿到。
这样，服务器将这个新的字符串给用户(即保存在cookie中，或保存在storage中)。用户每次访问，都会带上这个字符串(类似jsessionid)。服务器这边拿到用户带来的字符串，从中取出账号，将账号和服务器这边存。
字符串
在存储上类似字符数组，它每一位单个元素都是能提取的，字符串的零位是它的长度，如s[0]=10，这提供给我们很多方便，例如高精度运算时每一位都能转化为数字存入数组。
通常以串的整体作为操作对象，如：在串中查找某个子串、求取一个子串、在串的某个位置上插入一个子串以及删除一个子串等。
两个字符串相等的充要条件是：长度相等，并且各个对应位置上的字符都相等。设p、q是两个串，求q在p中首次出现的位置的运算叫做模式匹配。串的两种最基本的存储方式是顺序存储方式和链接存储方式。
⑥ 来，科普一下JWT
1. JSON Web Token是什么
JSON Web Token (JWT)是一个开放标准(RFC 7519)，它定义了一种紧凑的、自包含的方式，用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任，因为它是数字签名的。
2. 什么时候你应该用JSON Web Tokens
下列场景中使用JSON Web Token是很有用的：
Authorization (授权) : 这是使用JWT的最常见场景。一旦用户登录，后续每个请求都将包含JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是现在广泛使用的JWT的一个特性，因为它的开销很小，并且可以轻松地跨域使用。
Information Exchange (信息交换) : 对于安全的在各方之间传输信息而言，JSON Web Tokens无疑是一种很好的方式。因为JWTs可以被签名，例如，用公钥/私钥对，你可以确定发送人就是它们所说的那个人。另外，由于签名是使用头和有效负载计算的，您还可以验证内容没有被篡改。
3. JSON Web Token的结构是什么样的
JSON Web Token由三部分组成，它们之间用圆点(.)连接。这三部分分别是：
因此，一个典型的JWT看起来是这个样子的：
接下来，具体看一下每一部分：
Header
header典型的由两部分组成：token的类型（“JWT”）和算法名称（比如：HMAC SHA256或者RSA等等）。
例如：
然后，用Base64对这个JSON编码就得到JWT的第一部分
Payload
Public claims : 可以随意定义。
下面是一个例子：
对payload进行Base64编码就得到JWT的第二部分
Signature
为了得到签名部分，你必须有编码过的header、编码过的payload、一个秘钥，签名算法是header中指定的那个，然对它们签名即可。
例如：
签名是用于验证消息在传递过程中有没有被更改，并且，对于使用私钥签名的token，它还可以验证JWT的发送方是否为它所称的发送方。
看一张官网的图就明白了：
4. JSON Web Tokens是如何工作的
在认证的时候，当用户用他们的凭证成功登录以后，一个JSON Web Token将会被返回。此后，token就是用户凭证了，你必须非常小心以防止出现安全问题。一般而言，你保存令牌的时候不应该超过你所需要它的时间。
无论何时用户想要访问受保护的路由或者资源的时候，用户代理（通常是浏览器）都应该带上JWT，典型的，通常放在Authorization header中，用Bearer schema。
header应该看起来是这样的：
服务器上的受保护的路由将会检查Authorization header中的JWT是否有效，如果有效，则用户可以访问受保护的资源。如果JWT包含足够多的必需的数据，那么就可以减少对某些操作的数据库查询的需要，尽管可能并不总是如此。
如果token是在授权头（Authorization header）中发送的，那么跨源资源共享(CORS)将不会成为问题，因为它不使用cookie。
下面这张图显示了如何获取JWT以及使用它来访问APIs或者资源：
5. 基于Token的身份认证 与 基于服务器的身份认证
5.1. 基于服务器的身份认证
在讨论基于Token的身份认证是如何工作的以及它的好处之前，我们先来看一下以前我们是怎么做的：
HTTP协议是无状态的，也就是说，如果我们已经认证了一个用户，那么他下一次请求的时候，服务器不知道我是谁，我们必须再次认证
传统的做法是将已经认证过的用户信息存储在服务器上，比如Session。用户下次请求的时候带着Session ID，然后服务器以此检查用户是否认证过。
这种基于服务器的身份认证方式存在一些问题：
Sessions : 每次用户认证通过以后，服务器需要创建一条记录保存用户信息，通常是在内存中，随着认证通过的用户越来越多，服务器的在这里的开销就会越来越大。
Scalability : 由于Session是在内存中的，这就带来一些扩展性的问题。
CORS : 当我们想要扩展我们的应用，让我们的数据被多个移动设备使用时，我们必须考虑跨资源共享问题。当使用AJAX调用从另一个域名下获取资源时，我们可能会遇到禁止请求的问题。
CSRF : 用户很容易受到CSRF攻击。
5.2. JWT与Session的差异
相同点是，它们都是存储用户信息；然而，Session是在服务器端的，而JWT是在客户端的。
Session方式存储用户信息的最大问题在于要占用大量服务器内存，增加服务器的开销。
而JWT方式将用户状态分散到了客户端中，可以明显减轻服务端的内存压力。
Session的状态是存储在服务器端，客户端只有session id；而Token的状态是存储在客户端。
5.3. 基于Token的身份认证是如何工作的
基于Token的身份认证是无状态的，服务器或者Session中不会存储任何用户信息。
虽然这一实现可能会有所不同，但其主要流程如下：
注意：
5.4. 用Token的好处
无状态和可扩展性： Tokens存储在客户端。完全无状态，可扩展。我们的负载均衡器可以将用户传递到任意服务器，因为在任何地方都没有状态或会话信息。
安全： Token不是Cookie。（The token, not a cookie.）每次请求的时候Token都会被发送。而且，由于没有Cookie被发送，还有助于防止CSRF攻击。即使在你的实现中将token存储到客户端的Cookie中，这个Cookie也只是一种存储机制，而非身份认证机制。没有基于会话的信息可以操作，因为我们没有会话!
还有一点，token在一段时间以后会过期，这个时候用户需要重新登录。这有助于我们保持安全。还有一个概念叫token撤销，它允许我们根据相同的授权许可使特定的token甚至一组token无效。
5.5. JWT与OAuth的区别
写在最后：我为大家准备了一些适合于1－5年以上开发经验的java程序员面试涉及到的绝大部分面试题及答案做成了文档和学习笔记文件以及架构视频资料免费分享给大家（包括Dubbo、Redis、Netty、zookeeper、Spring cloud、分布式、高并发等架构技术资料），希望可以帮助到大家。
⑦ JWT令牌详解
JWT是JSON Web Token的缩写,是一个轻巧的规范,一个开放的行业标准,它定义了一种简洁的、自包含的协议格式,这个规范允许我们使用JWT在用户和服务器之间传递安全可靠的消息.
一个JWT实际上就是一个字符串,它由三部分组成,头部、荷载与签名
头部描述关于该JWT的最基本的信息,例如其类型以及签名所用的算法等
例如{"type":"JWT","alg":"HS256"}
其头部指明了签名算法是HS256算法
HMAC算法(非对称的)
SH256
RSA
荷载就是存放有效信息的地方
定义一个payload:{"sub":"1234567890","name":"John Doe","admin":true}
签证又由三部分组成,base64加密后的header和base64加密后的payload使用,连接组成的字符串
然后通过header中声明的加密方式进行加盐secret组合加密.
1、jwt基于json,非常方便解析
2、可以在令牌中自定义丰富的内容,易扩张
3、通过非对称加密算法以及数字签名技术,JWT防止篡改,安全性高
4、资源服务使用JWT可不依赖认证服务即可完成授权
JWT令牌较长,占存储空间比较大.
一个公钥对应一个私钥,私钥作为签名给JWT加密,那么这里需要生成与之对应的公钥:
输入密钥库口令: keytool -list -keystore changgou.jks
显示的信息为:
密钥库类型: jks
密钥库提供方: SUN
您的密钥库包含 1 个条目
changgou, 2020-7-28, PrivateKeyEntry,
证书指纹 (SHA1): 45:2E:51:8B:84:86:03:8C:AF:99:14:5F:4F:D6:98:33:39:92:33:79
输入命令后就可以得到公钥:
注释:classPathResource:私钥位置;
new KeyStoreKeyFactory:创建私钥工厂,需要私钥库密码和私钥位置两个参数;
keyStoreKeyFactory.getKeyPair(alias,password.toCharArray):获取keyPair对象,keyPair.getPrivate()即是获取私钥;
根据私钥获取令牌:JwtHelper.encode(JSON.toJSONString(map,new RsaSigner(rsaPrivateKey));