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));
来，科普一下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的缩写，它是基于 RFC 7519 标准定义的一种可以安全传输的的JSON对象，由于使用了数字签名，所以是可信任和安全的。
JWT token的格式：header.payload.signature
header中用于存放签名的生成算法
{"alg": "HS512"}Copy to clipboardErrorCopied
payload中用于存放用户名、token的生成时间和过期时间
{"sub":"admin","created":1489079981393,"exp":1489684781}Copy to clipboardErrorCopied
signature为以header和payload生成的签名，一旦header和payload被篡改，验证将失败
//secret为加密算法的密钥 String signature = HMACSHA512(base64UrlEncode(header) + "." +base64UrlEncode(payload),secret)
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应用的会话管理，其特点一般是：
总结
shiro（13）-JWT（Token的生成）
JWT（json web token）是为了在网络应用环境之间传递声明而执行的一种基于JSON的开放标准。
JWT的声明一般被用来在 身份提供者 和 服务提供者 间传递被认证的用户身份信息，以便从资源服务器获取资源。比如用于登录。
shiro（9）-有状态身份认证和无状态身份认证的区别
JWT由三部分组成：头部(header)、载荷(payload)、签名(signature)。头部定义类型和加密方式；载荷部分放的不是很重要的数据；签名使用定义的加密方式加密base64后的header和payload和一段自己加密key。最后的token由base64(header).base64(payload).base64(signature)组成。
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJvcmciOiLku4rml6XlpLTmnaEiLCJuYW1lIjoiRnJlZeeggeWGnCIsImV4cCI6MTUxNDM1NjEwMywiaWF0IjoxNTE0MzU2MDQzLCJhZ2UiOiIyOCJ9.49UF72vSkj-sA4aHHiYN5eoZ9Nb4w5Vb45PsLF7x_NY
JWT头部分是一个描述JWT元数据的JSON对象。
完整的头部就像下面这样的json。
然后将头部进行base64加密，构成第一部分：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
载荷是存放有效信息的地方，这些有效部分包含三个部分。
公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息， 但不建议添加敏感的信息，因为这部分在客户端可解密。
私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。
定义一个payload：
然后将其进行base64加密，得到第二部分
eyJvcmciOiLku4rml6XlpLTmnaEiLCJuYW1lIjoiRnJlZeeggeWGnCIsImV4cCI6MTUxNDM1NjEwMywiaWF0IjoxNTE0MzU2MDQzLCJhZ2UiOiIyOCJ9
jwt的第三部分是一个签证信息，这个签证信息由三部分组成：
这个部分需要base64加密后的header和base64加密后的payload使用 . 连接组成的字符串，然后通过header中声明的加密方式进行加盐secret组合加密，就构成了jwt的第三部分：
49UF72vSkj-sA4aHHiYN5eoZ9Nb4w5Vb45PsLF7x_NY
注：密钥secret是保存在服务端的，服务端会根据这个密钥进行生成token和验证，所以要保护好。
解析结果
重放攻击是攻击者获取客户端发送给服务器端的包，不做修改，原封不动的发送给服务器用来实现某些功能。比如说客户端发送给服务器端一个包的功能是查询某个信息，攻击者拦截到这个包，然后想要查询这个信息的时候，把这个包发送给服务器，服务器就会做相应的操作，返回查询的信息。
鉴权必须了解的 5 个兄弟：cookie、session、token、jwt、单点登录
本文你将看到：
**「前端存储」**这就涉及到一发、一存、一带，发好办，登陆接口直接返回给前端，存储就需要前端想办法了。
前端的存储方式有很多。
有，cookie。cookie 也是前端存储的一种，但相比于 localStorage 等其他方式，借助 HTTP 头、浏览器能力，cookie 可以做到前端无感知。一般过程是这样的：
「配置：Domain / Path」
cookie 是要限制::「空间范围」::的，通过 Domain（域）/ Path（路径）两级。
「配置：Expires / Max-Age」
cookie 还可以限制::「时间范围」::，通过 Expires、Max-Age 中的一种。
「配置：Secure / HttpOnly」
cookie 可以限制::「使用方式」::。
**「HTTP 头对 cookie 的读写」**回过头来，HTTP 是如何写入和传递 cookie 及其配置的呢？HTTP 返回的一个 Set-Cookie 头用于向浏览器写入「一条（且只能是一条）」cookie，格式为 cookie 键值 + 配置键值。例如：
那我想一次多 set 几个 cookie 怎么办？多给几个 Set-Cookie 头（一次 HTTP 请求中允许重复）
HTTP 请求的 Cookie 头用于浏览器把符合当前「空间、时间、使用方式」配置的所有 cookie 一并发给服务端。因为由浏览器做了筛选判断，就不需要归还配置内容了，只要发送键值就可以。
**「前端对 cookie 的读写」**前端可以自己创建 cookie，如果服务端创建的 cookie 没加HttpOnly，那恭喜你也可以修改他给的 cookie。调用document.cookie可以创建、修改 cookie，和 HTTP 一样，一次document.cookie能且只能操作一个 cookie。
调用document.cookie也可以读到 cookie，也和 HTTP 一样，能读到所有的非HttpOnly cookie。
现在回想下，你刷卡的时候发生了什么？
这种操作，在前后端鉴权系统中，叫 session。典型的 session 登陆/验证流程：
**「Session 的存储方式」**显然，服务端只是给 cookie 一个 sessionId，而 session 的具体内容（可能包含用户信息、session 状态等），要自己存一下。存储的方式有几种：
「Session 的过期和销毁」**很简单，只要把存储的 session 数据销毁就可以。****「Session 的分布式问题」**通常服务端是集群，而用户请求过来会走一次负载均衡，不一定打到哪台机器上。那一旦用户后续接口请求到的机器和他登录请求的机器不一致，或者登录请求的机器宕机了，session 不就失效了吗？这个问题现在有几种解决方式。
但通常还是采用第一种方式，因为第二种相当于阉割了负载均衡，且仍没有解决「用户请求的机器宕机」的问题。**「node.js 下的 session 处理」**前面的图很清楚了，服务端要实现对 cookie 和 session 的存取，实现起来要做的事还是很多的。在npm中，已经有封装好的中间件，比如 express-session - npm，用法就不贴了。这是它种的 cookie：
express-session - npm 主要实现了：
session 的维护给服务端造成很大困扰，我们必须找地方存放它，又要考虑分布式的问题，甚至要单独为了它启用一套 Redis 集群。有没有更好的办法？
回过头来想想，一个登录场景，也不必往 session 存太多东西，那为什么不直接打包到 cookie 中呢？这样服务端不用存了，每次只要核验 cookie 带的「证件」有效性就可以了，也可以携带一些轻量的信息。这种方式通常被叫做 token。
token 的流程是这样的：
**「客户端 token 的存储方式」 在前面 cookie 说过，cookie 并不是客户端存储凭证的唯一方式。token 因为它的「无状态性」，有效期、使用限制都包在 token 内容里，对 cookie 的管理能力依赖较小，客户端存起来就显得更自由。但 web 应用的主流方式仍是放在 cookie 里，毕竟少操心。 「token 的过期」**那我们如何控制 token 的有效期呢？很简单，把「过期时间」和数据一起塞进去，验证时判断就好。
编码的方式丰俭由人。**「base64」**比如 node 端的 cookie-session - npm 库
默认配置下，当我给他一个 userid，他会存成这样：
这里的 eyJ1c2VyaWQiOiJhIn0=，就是 {"userid":"abb”} 的 base64 而已。 「防篡改」
是的。所以看情况，如果 token 涉及到敏感权限，就要想办法避免 token 被篡改。解决方案就是给 token 加签名，来识别 token 是否被篡改过。例如在 cookie-session - npm 库中，增加两项配置：
这样会多种一个 .sig cookie，里面的值就是 {"userid":"abb”} 和 iAmSecret通过加密算法计算出来的，常见的比如HMACSHA256 类 (System.Security.Cryptography) | Microsoft Docs。
好了，现在 cdd 虽然能伪造出eyJ1c2VyaWQiOiJhIn0=，但伪造不出 sig 的内容，因为他不知道 secret。**「JWT」**但上面的做法额外增加了 cookie 数量，数据本身也没有规范的格式，所以 JSON Web Token Introduction - jwt.io 横空出世了。
它是一种成熟的 token 字符串生成方案，包含了我们前面提到的数据、签名。不如直接看一下一个 JWT token 长什么样：
这串东西是怎么生成的呢？看图：
类型、加密算法的选项，以及 JWT 标准数据字段，可以参考 RFC 7519 - JSON Web Token (JWT)node 上同样有相关的库实现：express-jwt - npm koa-jwt - npm
token，作为权限守护者，最重要的就是「安全」。业务接口用来鉴权的 token，我们称之为 access token。越是权限敏感的业务，我们越希望 access token 有效期足够短，以避免被盗用。但过短的有效期会造成 access token 经常过期，过期后怎么办呢？一种办法是，让用户重新登录获取新 token，显然不够友好，要知道有的 access token 过期时间可能只有几分钟。另外一种办法是，再来一个 token，一个专门生成 access token 的 token，我们称为 refresh token。
有了 refresh token 后，几种情况的请求流程变成这样：
如果 refresh token 也过期了，就只能重新登录了。
session 和 token 都是边界很模糊的概念，就像前面说的，refresh token 也可能以 session 的形式组织维护。狭义上，我们通常认为 session 是「种在 cookie 上、数据存在服务端」的认证方案，token 是「客户端存哪都行、数据存在 token 里」的认证方案。对 session 和 token 的对比本质上是「客户端存 cookie / 存别地儿」、「服务端存数据 / 不存数据」的对比。**「客户端存 cookie / 存别地儿」**存 cookie 固然方便不操心，但问题也很明显：
存别的地方，可以解决没有 cookie 的场景；通过参数等方式手动带，可以避免 CSRF 攻击。 「服务端存数据 / 不存数据」
前面我们已经知道了，在同域下的客户端/服务端认证系统中，通过客户端携带凭证，维持一段时间内的登录状态。但当我们业务线越来越多，就会有更多业务系统分散到不同域名下，就需要「一次登录，全线通用」的能力，叫做「单点登录」。
简单的，如果业务系统都在同一主域名下，比如wenku.baidu.com tieba.baidu.com，就好办了。可以直接把 cookie domain 设置为主域名 baidu.com，百度也就是这么干的。
比如滴滴这么潮的公司，同时拥有didichuxing.com xiaojukeji.com didiglobal.com等域名，种 cookie 是完全绕不开的。这要能实现「一次登录，全线通用」，才是真正的单点登录。这种场景下，我们需要独立的认证服务，通常被称为 SSO。 「一次「从 A 系统引发登录，到 B 系统不用登录」的完整流程」
**「完整版本：考虑浏览器的场景」**上面的过程看起来没问题，实际上很多 APP 等端上这样就够了。但在浏览器下不见得好用。看这里：
对浏览器来说，SSO 域下返回的数据要怎么存，才能在访问 A 的时候带上？浏览器对跨域有严格限制，cookie、localStorage 等方式都是有域限制的。这就需要也只能由 A 提供 A 域下存储凭证的能力。一般我们是这么做的：
图中我们通过颜色把浏览器当前所处的域名标记出来。注意图中灰底文字说明部分的变化。
谢谢大家哦