security + oauth2 + jwt + gateway 实现统一身份认证和鉴权（基础）

JWT是由三段信息构成的，将这三段信息文本用.链接一起就构成了Jwt字符串。就像这样: jwt的头部承载两部分信息： 声明类型，这里是jwt 声明加密的算法 通常直接使用 HMAC SHA256 完整的头部就像下面这样的JSON： 然后将头部进行base64加密（该加密是可以对称解密的),构成了第一部分. 载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品，这些有效信息包含三个部分 标准中注册的声明 公共的声明 私有的声明 标准中注册的声明 (建议但不强制使用) ： 公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端可解密. 私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。 定义一个payload: 然后将其进行base64加密，得到Jwt的第二部分。 jwt的第三部分是一个签证信息，这个签证信息由三部分组成： 这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串，然后通过header中声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分。 将这三部分用.连接成一个完整的字符串,构成了最终的jwt: 一般是在请求头里加入Authorization，并加上Bearer标注：

如今，越来越多的项目开始采用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应用的会话管理，其特点一般是： 总结

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、分布式、高并发等架构技术资料），希望可以帮助到大家。

JSON Web Token（JWT）作为目前最流行的跨域认证方案大家都不陌生了吧。很多系统都在使用JWT替代session认证，这两者有啥区别呢？ 简言之，JWT是将认证后的数据保存在客户端，session是保存在服务器端。 使用JWT替代session认证后，服务器不用维护session，分布式环境下不需要单点存储session。因为JWT的自解释性，只要验证JWT是否合法就OK啦。大大提升了系统的可扩展性，特别适合当下微服务大行其道的大环境。 加入一个 但是。。。 老板想要实现踢人，封号怎么办呢？ 第一个想法就是颁布jwt时，把jwt存到一个中心redis中。每次访问验证jwt时看看redis里是否有这个token，没有这个token就认证失败。踢人封号只用把用户关联的jwt删除掉就ok了！就可以愉快的回家抱媳妇了（抱歉可能你没有）。 且慢，这么玩完全违背了jwt的初衷，服务器又变了有状态了，何苦脱裤子放屁呢，直接用session不就完了？ 讲真的jwt的设计也不太适合这样的场景。 可以采用类似oauth2.0协议中的做法，认证后颁布2个token，access token和refresh token。 客户端要长时间维护登录态，就需要当访问令牌失效后，自动使用刷新令牌获取新的访问令牌。或者在访问令牌失效之前，提前刷新令牌。 现在我们想要踢人，只需要将用户相关的刷新令牌从redis里删除。当前的访问令牌失效后，自然也没有办法再刷新令牌了。从而达到强制用户登出的目的。 这么设计有个缺陷就是强制用户登出不是及时的。需要有一个等待访问令牌过期的时间。如果希望及时性高点，可以将访问令牌的过期时间设置短一点，但刷新token的频率就会升高。这个需要根据自己的业务进行权衡。 每次调用服务api时仍然是原汁原味的jwt无状态认证，无需访问任何中心存储。仅在刷新访问令牌的时候需要访问中心存储。也算是一种折中的方案。 欢迎关注作者的github项目，学习微服务： 一个支持多店铺的电商系统，基于Spring Boot的微服务构架 https://github.com/ikeyit/ikeyit-services 一个基于React的电商管理后台 https://github.com/ikeyit/ikeyit-management-web

jwt和token区别为主要体现在接收的信息是否需要进入数据库查询信息。Token需要查库验证token是否有效，而JWT不用查库，直接在服务端进行校验，因为用户的信息及加密信息，和过期时间，都在JWT里，只要在服务端进行校验就行，并且校验也是JWT自己实现的。JWT是json web token缩写。它将用户信息加密到token里，服务器不保存任何用户信息。服务器通过使用保存的密钥验证JWT Token的正确性，只要正确即通过验证。JWT包含三个部分： Header头部，Payload负载和Signature签名。由三部分生成Jwt Token，三部分之间用“.”号做分割， 校验也是JWT内部自己实现的。Token基本原理：1、客户端使用用户名跟密码请求登录。2、服务端收到请求，去验证用户名与密码。3、验证成功，服务端会签发一个Token保存到（Session，redis，mysql）中，然后再把这个Token发送给客户端。4、客户端收到Token以后可以把它存储起来，比如放在Cookie里或者Local Storage里。5、客户端每次向服务端请求资源的时候需要带着服务端签发的Token。6、服务端收到请求，验证密客户端请求里面带着的Token和服务器中保存的Token进行对比校验， 如果验证成功，就向客户端返回请求的数据。

通过 JWT 配合 Spring Security OAuth2 使用的方式，可以避免 每次请求 都 远程调度 认证授权服务。 资源服务器 只需要从 授权服务器 验证一次，返回 JWT。返回的 JWT 包含了 用户 的所有信息，包括 权限信息 。 1. 什么是JWT JSON Web Token（JWT）是一种开放的标准（RFC 7519），JWT 定义了一种 紧凑 且 自包含 的标准，旨在将各个主体的信息包装为 JSON 对象。 主体信息 是通过 数字签名 进行 加密 和 验证 的。经常使用 HMAC 算法或 RSA（ 公钥 / 私钥 的 非对称性加密 ）算法对 JWT 进行签名， 安全性很高 。 2. JWT的结构 JWT 的结构由三部分组成：Header（头）、Payload（有效负荷）和 Signature（签名）。因此 JWT 通常的格式是 xxxxx.yyyyy.zzzzz。 2.1. Header Header 通常是由 两部分 组成：令牌的 类型 （即 JWT）和使用的 算法类型 ，如 HMAC、SHA256 和 RSA。例如: 将 Header 用 Base64 编码作为 JWT 的 第一部分 ，不建议在 JWT 的 Header 中放置 敏感信息 。 2.2. Payload 下面是 Payload 部分的一个示例： 将 Payload 用 Base64 编码作为 JWT 的 第二部分 ，不建议在 JWT 的 Payload 中放置 敏感信息 。 2.3. Signature 要创建签名部分，需要利用 秘钥 对 Base64 编码后的 Header 和 Payload 进行 加密 ，加密算法的公式如下： 签名 可以用于验证 消息 在 传递过程 中有没有被更改。对于使用 私钥签名 的 token，它还可以验证 JWT 的 发送方 是否为它所称的 发送方 。 3. JWT的工作方式 客户端 获取 JWT 后，对于以后的 每次请求 ，都不需要再通过 授权服务 来判断该请求的 用户 以及该 用户的权限 。在微服务系统中，可以利用 JWT 实现 单点登录 。认证流程图如下： 4. 案例工程结构 工程原理示意图如下: 5. 构建auth-service授权服务 UserServiceDetail.java UserRepository.java 实体类 User 和上一篇文章的内容一样，需要实现 UserDetails 接口，实体类 Role 需要实现 GrantedAuthority 接口。 User.java Role.java jks 文件的生成需要使用 Java keytool 工具，保证 Java 环境变量没问题，输入命令如下： 其中，-alias 选项为 别名 ，-keyalg 为 加密算法 ，-keypass 和 -storepass 为 密码选项 ，-keystore 为 jks 的 文件名称 ，-validity 为配置 jks 文件 过期时间 （单位：天）。 生成的 jks 文件作为 私钥 ，只允许 授权服务 所持有，用作 加密生成 JWT。把生成的 jks 文件放到 auth-service 模块的 src/main/resource 目录下即可。 对于 user-service 这样的 资源服务 ，需要使用 jks 的 公钥 对 JWT 进行 解密 。获取 jks 文件的 公钥 的命令如下： 这个命令要求安装 openSSL 下载地址，然后手动把安装的 openssl.exe 所在目录配置到 环境变量 。 输入密码 fzp123 后，显示的信息很多，只需要提取 PUBLIC KEY，即如下所示： 新建一个 public.cert 文件，将上面的 公钥信息 复制到 public.cert 文件中并保存。并将文件放到 user-service 等 资源服务 的 src/main/resources 目录下。至此 auth-service 搭建完毕。 maven 在项目编译时，可能会将 jks 文件 编译 ，导致 jks 文件 乱码 ，最后不可用。需要在 pom.xml 文件中添加以下内容： 6. 构建user-service资源服务 注入 JwtTokenStore 类型的 Bean，同时初始化 JWT 转换器 JwtAccessTokenConverter，设置用于解密 JWT 的 公钥 。 配置 资源服务 的认证管理，除了 注册 和 登录 的接口之外，其他的接口都需要 认证 。 新建一个配置类 GlobalMethodSecurityConfig，通过 @EnableGlobalMethodSecurity 注解开启 方法级别 的 安全验证 。 拷贝 auth-service 模块的 User、Role 和 UserRepository 三个类到本模块。在 Service 层的 UserService 编写一个 插入用户 的方法，代码如下： 配置用于用户密码 加密 的工具类 BPwdEncoderUtil： 实现一个 用户注册 的 API 接口 /user/register，代码如下： 在 Service 层的 UserServiceDetail 中添加一个 login() 方法，代码如下： AuthServiceClient 作为 Feign Client，通过向 auth-service 服务接口 /oauth/token 远程调用获取 JWT。在请求 /oauth/token 的 API 接口中，需要在 请求头 传入 Authorization 信息， 认证类型 ( grant_type )、用户名 ( username ) 和 密码 ( password )，代码如下： 其中，AuthServiceHystrix 为 AuthServiceClient 的 熔断器 ，代码如下： JWT 包含了 access_token、token_type 和 refresh_token 等信息，代码如下： UserLoginDTO 包含了一个 User 和一个 JWT 成员属性，用于返回数据的实体： 登录异常类 UserLoginException 全局异常处理 切面类 ExceptionHandle 在 Web 层的 UserController 类中新增一个登录的 API 接口 /user/login 如下： 依次启动 eureka-service，auth-service 和 user-service 三个服务。 7. 使用Postman测试 因为没有权限，访问被拒绝。在数据库手动添加 ROLE_ADMIN 权限，并与该用户关联。重新登录并获取 JWT，再次请求 /user/foo 接口。 在本案例中，用户通过 登录接口 来获取 授权服务 加密后的 JWT。用户成功获取 JWT 后，在以后每次访问 资源服务 的请求中，都需要携带上 JWT。 资源服务 通过 公钥解密 JWT， 解密成功 后可以获取 用户信息 和 权限信息 ，从而判断该 JWT 所对应的 用户 是谁，具有什么 权限 。 获取一次 Token，多次使用， 资源服务 不再每次访问 授权服务 该 Token 所对应的 用户信息 和用户的 权限信息 。 一旦 用户信息 或者 权限信息 发生了改变，Token 中存储的相关信息并 没有改变 ，需要 重新登录 获取新的 Token。就算重新获取了 Token，如果原来的 Token 没有过期，仍然是可以使用的。一种改进方式是在登录成功后，将获取的 Token 缓存 在 网关上 。如果用户的 权限更改 ，将 网关 上缓存的 Token 删除 。当请求经过 网关 ，判断请求的 Token 在 缓存 中是否存在，如果缓存中不存在该 Token，则提示用户 重新登录 。

JWT是JSON WEB TOKEN的缩写，它是基于 RFC 7519 标准定义的一种可以安全传输的的JSON对象，由于使用了数字签名，所以是可信任和安全的。JWT token的格式：header.payload.signatureheader中用于存放签名的生成算法{"alg": "HS512"}Copy to clipboardErrorCopiedpayload中用于存放用户名、token的生成时间和过期时间{"sub":"admin","created":1489079981393,"exp":1489684781}Copy to clipboardErrorCopiedsignature为以header和payload生成的签名，一旦header和payload被篡改，验证将失败//secret为加密算法的密钥 String signature = HMACSHA512(base64UrlEncode(header) + "." +base64UrlEncode(payload),secret)

简单来说是一种令牌（用户访问系统的通行证），该令牌是使用用户的一些非隐私信息经过加密和签名得到的唯一凭证。该令牌由服务器端生成，保存与客户端。 JWT由三部分组成：头(header)，载荷(payload)，签名(signature)，然后将这三部分经过加密以后使用点(.)连接起来构成token字符串。 header.payload.signature 例:eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoibGlseSIsImlkIjoiMSIsImV4cCI6MTY1MDE3ODk2OH0.7S2dZoxCVBcrNjg31SV5u6ngChhoMPIWoh-ZB3kknnw 2.简单案例（模拟登录）： 由于spring系列已经内嵌了jackson-...，以及其它的一些jar包，故只需引入jwt或者jjwt的pom坐标就可以在项目中使用了，所以此处不赘述spring系列关于jwt的使用

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和验证，所以要保护好。 解析结果 重放攻击是攻击者获取客户端发送给服务器端的包，不做修改，原封不动的发送给服务器用来实现某些功能。比如说客户端发送给服务器端一个包的功能是查询某个信息，攻击者拦截到这个包，然后想要查询这个信息的时候，把这个包发送给服务器，服务器就会做相应的操作，返回查询的信息。

A JWT token contains a Header, a Payload, and a Signature. Header Header contains the algorithms like RSA or HMACSHA256 and the information of the type of Token. Payload Payload contains the information of rows, i.e., user credentials. How Does JWT Work? Step 1 Client logs in with his/her credentials. Step 2 Server generates a Jwt token at server side. Step 3 After token generation, the server returns a token in response. Step 4 Now, the client sends a copy of the token to validate the token. Step 5 The server checks JWT token to see if it"s valid or not. Step 6 After the token is validated, the server sends a status message to the client. [图片上传中...(-4ee818-1642837712343-0)] 授权流程： 1、用户请求登录，携带用户名密码到授权中心 2、授权中心携带用户名密码，到用户中心查询用户 3、查询如果正确，生成JWT凭证 4、返回JWT给用户 鉴权流程： 1、用户请求某微服务功能，携带JWT 2、微服务将jwt交给授权中心校验 3、授权中心返回校验结果到微服务 4、微服务判断校验结果，成功或失败 5、失败则直接返回401 6、成功则处理业务并返回

1.问题描述jwt与token+redis，哪种方案更好用？问题结论刚好最近有项目使用了jwt，而且是定制化的jwt的认证机制，就个人的理解而言，各自有其优缺点，并且针对不同的场景需要进行约束性开发，如用户剔除、同一用户每2h只生成一次jwt等。2.Token机制简述2.1Token的用途用户在登录APP时，APP端会发送加密的用户名和密码到服务器，服务器验证用户名和密码，如果验证成功，就会生成相应位数的字符产作为token存储到服务器中，并且将该token返回给APP端。以后APP再次请求时，凡是需要验证的地方都要带上该token，然后服务器端验证token，成功返回所需要的结果，失败返回错误信息，让用户重新登录。其中，服务器上会给token设置一个有效期，每次APP请求的时候都验证token和有效期。在存储的时候把token进行对称加密存储，用到的时候再解密。文章最开始提到的签名sign：将请求URL、时间戳、token三者合并，通过算法进行加密处理。2.2token+redis机制用户验证通过后，服务端通过如uuid相关的方法，生成token，存储用户信息。当请求服务时，客户端将token带上来，进行查询验证，如token存在并在有限期内，请求有效，否则请求非法。token+redis机制是中心化的，每次验证token有效性时，都需要访问redis，其核心优点实服务端可以主动让token失效，缺点是每次都要进行redis查询。占用redis存储空间。2.3jwt机制这是一种无状态身份验证机制，因为用户状态永远不会保存在服务器内存中。服务器受保护的路由将在授权头中检查有效的JWT，如果存在，则允许用户访问受保护的资源。由于JWT是独立的，所有必要的信息都在那里，减少了多次查询数据库的需求。Javajwt普遍选用java-jwt工具包依赖，gradle依赖：compile"com.auth0:java-jwt:3.2.0"用户发起登录请求，验证通过后，服务端创建一个加密后的JWT信息，作为Token返回。在后续请求中JWT信息作为请求头，发给服务端。服务端拿到JWT之后进行解密，正确解密表示此次请求合法，验证通过；解密失败说明Token无效或者已过期。jwt的有点主要有：a.其是去中心化的，便于分布式系统使用；2.基本信息可以直接放在token中。user_id，session_id；3.功能权限信息可以直接放在token中。用bit位表示用户所具有的功能权限。其缺点有：服务端无法主动让token失效，另一个是无法很好的控制payload的数据量。3.小结jwt和token+redis两种方案，没有最优，只有结合不同的业务场景，需求最适合的方案。就比如token2h过期，同一用户每1.5h只生成一次token，当两次token并存时，同时有效。大家可以考虑在这两种方案的前提下，分别如何实现？

注：参考 Spring Security 整合 JSON Web Token(JWT) 提升 REST 安全性 ，写的特别全面，本文只是学习总结基于token的鉴权机制基于token的鉴权机制类似于http协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利。 流程上是这样的： 1.用户使用用户名密码来请求服务器 2.服务器进行验证用户的信息 3.服务器通过验证发送给用户一个token 4.客户端存储token，并在每次请求时附送上这个token值 5.服务端验证token值，并返回数据 这个token必须要在每次请求时传递给服务端，它应该保存在请求头里， 另外，服务端要支持CORS(跨来源资源共享)策略，一般我们在服务端这么做就可以了Access-Control-Allow-Origin: *。 第一部分我们称它为头部（header),第二部分我们称其为载荷（payload, 类似于飞机上承载的物品)，第三部分是签证（signature). jwt的头部承载两部分信息： 声明类型，这里是jwt 声明加密的算法 通常直接使用 HMAC SHA256 完整的头部就像下面这样的JSON： 然后将头部进行base64加密（该加密是可以对称解密的),构成了第一部分. 载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品，这些有效信息包含三个部分 1.标准中注册的声明 2.公共的声明 3.私有的声明 标准中注册的声明 (建议但不强制使用) ： iss : jwt签发者 sub : jwt所面向的用户 aud : 接收jwt的一方 exp : jwt的过期时间，这个过期时间必须要大于签发时间 nbf : 定义在什么时间之前，该jwt都是不可用的. iat : jwt的签发时间 jti : jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击。 公共的声明 ： 公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端可解密. 私有的声明 ： 私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。 定义一个payload: 然后将其进行base64加密，得到Jwt的第二部分。 jwt的第三部分是一个签证信息，这个签证信息由三部分组成： 1.header (base64后的) 2.payload (base64后的) 3.secret 这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串，然后通过header中声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分。 将这三部分用.连接成一个完整的字符串,构成了最终的jwt: 注意：secret是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和jwt的验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。 如何应用 一般是在请求头里加入Authorization，并加上Bearer标注： 服务端会验证token，如果验证通过就会返回相应的资源。整个流程就是这样的: jwt-diagram 总结 优点 因为json的通用性，所以JWT是可以进行跨语言支持的，像JAVA,JavaScript,NodeJS,PHP等很多语言都可以使用。 因为有了payload部分，所以JWT可以在自身存储一些其他业务逻辑所必要的非敏感信息。 便于传输，jwt的构成非常简单，字节占用很小，所以它是非常便于传输的。 它不需要在服务端保存会话信息, 所以它易于应用的扩展 安全相关 不应该在jwt的payload部分存放敏感信息，因为该部分是客户端可解密的部分。 保护好secret私钥，该私钥非常重要。 如果可以，请使用https协议 在SpringBoot中整合JWTSpring Security的步奏： 1.在项目中引入（本项目使用Gradle） 2.配置 目录结构如下： WebSecurityConfig文件：

我们来继续前两章（ OAuth2 总结 , 对OpenID Connect的理解 ）的讨论，进入对JWT的理解。先来简单回顾一下OAuth2和OpenID： OpenID建立在OAuth之上，完成了认证和授权。而认证和授权的结果就体现在这个ID token之上，而这个ID token通常会是JWT。那么为什么会是JWT呢？我们通过以下几点来逐一解释。 JWT RFC 7519 给出了官方定义的一些字段： 当然也不限于此，可以根据自己的需要，添加其他字段。到此，我们可以看出JWT提供了ID token所需要的能力。一个完整的JTW是由三部分组成：Header，Payload，Signature。三者之间由 . 隔开，刚才提到的认证授权的字段就存在于Payload中。 Header中存放的是JTW的元数据，包含签名的算法以及token的类型，如下所示： Signature部分是对前两部分的签名， 防止数据篡改 。首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。 算出签名以后，把 Header、Payload、Signature三个部分经过base64序列化为三个字符串，再讲三个字符串由 . 为间隔拼接成一个字符串返回给客户端。 ID Token需要有足够的安全性，JWT是如何做到的呢？ 刚看到了签名部分，签名的作用只是为了防止数据篡改，而JWT默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。比如认证服务器中使用私钥进行加密，把公钥分发给其他应用服务器，应用服务拿到加密后的token后用公钥解密，获取到JWT，再用签名的秘钥来验证数据是否经过的篡改。 我们来看看还有神马其他备选么？Simple Web Tokens (SWT)和Security Assertion Markup Language Tokens (SAML)。 JWT vs SAML：JWT基于json，而SAML基于XML，在大小上就有足够的优势，更适用于HTML和HTTP。 JWT vs SWT：在安全性上，SWT只支持对称加密，而JWT和SAML支持公私钥的加密方式。 作为一个mobile developer，也想在这里对比一下原先的简单token模式和SSO中的JWT： 在没有该机制前，我们通常会使用一个随机产生的字符串作为token，认证成功后返回给前端，之后前端的每个请求带上这个token。若后台服务的是个单体应用没有什么问题，请求来了，验证一下token是否有效即可，但当认证服务和其他的应用服务是分离的，怎么做呢？应用服务受到请求，再向认证服务发起一个请求来验证验证token是否合法，是否有权限访问该应用服务。这样做到没有什么问题，只是当服务变多时，比如微服务下，势必会造成认证服务器的压力过大。 在使用该机制后，客户端通过认证服务登录，获得这个JWT，之后其他应用服务自身便可以验证这个token的是否有效，是否有权访问。 看似完美，但也有它自身的问题，我们来看一个场景：权限变更。某用户原先是一个超级管理员，可以访问所有服务，并可进行任意的删除，更改操作，他在这个状态下拿到了JWT。随后，由于权限更改为普通管理员，便不应该具有所有权限，但此时他开始时的JWT被缓存在客户端仍然可用，其他应用服务也并无法知道这个用户的权限已经被更改，后果可想而知了。解决的方式无非是将这个token的有效时间设置的短一些。

用户登录时调用后端认证接口，后端验证用户成功之后生成两个token，access_token和refresh_token，后端将用户信息和这两个token打包成JWT后并返回给前端。前端在获取到登录成功返回的两个token之后，将之存放到localStorage本地存储中。JWT设置了过期时间以后，一定超过，那么接口就不能访问了，需要用户重新登录获取token。如果经常需要用户重新登录，显然这种体验不是太好，因此很多应用会采用token过期后自动续期的方案，只有特定条件下才会让用户重新登录。JWT是一种授权的场景，可以用来在非常有限的时间内允许用户使用服务终端访问服务器，在整个会话过程中JWT用户身份认证，JWT也会存在过期，这时就需要进行更新处理，以达到提升安全性的目的。

GWT单点登录原理这是一个技术原始问题，服务器这边准备一个密码字符串，各服务器保持字符串一样。当用户登录一台服务器成功后，服务器将他的账号和密码字符串通过算法整合一下，形成一个新的字符串。通常这个算法会将密码字符串用哈希的方式来处理，但账号可以直接在新的字符串中拿到。这样，服务器将这个新的字符串给用户(即保存在cookie中，或保存在storage中)。用户每次访问，都会带上这个字符串(类似jsessionid)。服务器这边拿到用户带来的字符串，从中取出账号，将账号和服务器这边存。字符串在存储上类似字符数组，它每一位单个元素都是能提取的，字符串的零位是它的长度，如s[0]=10，这提供给我们很多方便，例如高精度运算时每一位都能转化为数字存入数组。通常以串的整体作为操作对象，如：在串中查找某个子串、求取一个子串、在串的某个位置上插入一个子串以及删除一个子串等。两个字符串相等的充要条件是：长度相等，并且各个对应位置上的字符都相等。设p、q是两个串，求q在p中首次出现的位置的运算叫做模式匹配。串的两种最基本的存储方式是顺序存储方式和链接存储方式。

jwt一般存在在sessionStorage、cookie或localStorage里。jwt即JSON Web Token，是一种认证协议，一般用来校验请求的身份信息和身份权限。sessionStorage是会话级存储，关闭页面或浏览器后会被清除；用cookie存储时需要注意防范CSRF攻击，前网页的URL要与请求目标一致；用localStorage存储不易受到CSRF的影响，需要通过代码来实现，容易受到XSS攻击。

OAuth2是一个关于授权的开放标准，核心思路是通过各类认证手段（具体什么手段OAuth2不关心）认证用户身份，并颁发token（令牌），使得第三方应用可以使用该令牌在 限定时间 、 限定范围 访问指定资源。主要涉及的RFC规范有 RFC6749 （整体授权框架）, RFC6750 （令牌使用）, RFC6819 （威胁模型）这几个，一般我们需要了解的就是 RFC6749 。获取令牌的方式主要有四种，分别是 授权码模式 ， 简单模式 ， 密码模式 和 客户端模式 ，如何获取token不在本篇文章的讨论范围，我们这里假定客户端已经通过某种方式获取到了access_token，想了解具体的oauth2授权步骤可以移步阮一峰老师的 理解OAuth 2.0 ，里面有非常详细的说明。 这里要先明确几个OAuth2中的几个重要概念： 明确概念后，就可以看OAuth2的协议握手流程，摘自RFC6749 Spring Security是一套安全框架，可以基于RBAC（基于角色的权限控制）对用户的访问权限进行控制，核心思想是通过一系列的filter chain来进行拦截过滤，以下是ss中默认的内置过滤器列表，当然你也可以通过 custom-filter 来自定义扩展filter chain列表 这里面最核心的就是 FILTER_SECURITY_INTERCEPTOR ，通过 FilterInvocationSecurityMetadataSource 来进行资源权限的匹配， AccessDecisionManager 来执行访问策略。 一般意义来说的应用访问安全性，都是围绕认证（Authentication）和授权（Authorization）这两个核心概念来展开的。即首先需要确定用户身份，在确定这个用户是否有访问指定资源的权限。认证这块的解决方案很多，主流的有 CAS 、 SAML2 、 OAUTH2 等（不巧这几个都用过-_-），我们常说的单点登录方案（SSO）说的就是这块，授权的话主流的就是spring security和shiro。shiro我没用过，据说是比较轻量级，相比较而言spring security确实架构比较复杂。 将OAuth2和Spring Security集成，就可以得到一套完整的安全解决方案。 为了便于理解，现在假设有一个名叫“脸盆网”的社交网站，用户在首次登陆时会要求导入用户在facebook的好友列表，以便于快速建立社交关系。具体的授权流程如下： 不难看出，这个假设的场景中，脸盆网就是第三方应用（client），而facebook既充当了认证服务器，又充当了资源服务器。这个流程里面有几个比较重要的关键点，我需要重点说一下，而这也是其他的涉及spring security与OAuth2整合的文章中很少提及的，很容易云里雾里的地方。 细心的同学应该发现了，其实在标准的OAuth2授权过程中，5、6、8这几步都不是必须的，从上面贴的 RFC6749 规范来看，只要有1、2、3、4、7这几步，就完成了被保护资源访问的整个过程。事实上， RFC6749 协议规范本身也并不关心用户身份的部分，它只关心token如何颁发，如何续签，如何用token访问被保护资源（facebook只要保证返回给脸盆网的就是当前用户的好友，至于当前用户是谁脸盆网不需要关心）。那为什么spring security还要做5、6这两步呢？这是因为spring security是一套完整的安全框架，它必须关心用户身份！在实际的使用场景中，OAuth2一般不仅仅用来进行被保护资源的访问，还会被用来做单点登陆（SSO）。在SSO的场景中，用户身份无疑就是核心，而token本身是不携带用户信息的，这样client就没法知道认证服务器发的token到底对应的是哪个用户。设想一下这个场景，脸盆网不想自建用户体系了，想直接用facebook的用户体系，facebook的用户和脸盆网的用户一一对应（其实在很多中小网站现在都是这种模式，可以选择使用微信、QQ、微博等网站的用户直接登陆），这种情况下，脸盆网在通过OAuth2的认证后，就希望拿到用户信息了。所以现在一般主流的OAuth2认证实现，都会预留一个用户信息获取接口，就是上面提到的 https://api.facebook.com/user (虽然这不是OAuth2授权流程中必须的)，这样client在拿到token后，就可以携带token通过这个接口获取用户信息，完成SSO的整个过程。另外从用户体验的角度来说，如果获取不到用户信息，则意味者每次要从脸盆网访问facebook的资源，都需要重定向一次进行认证，用户体验也不好。 首先要明确一点， OAuth2并不是一个SSO框架，但可以实现SSO功能 。以下是一个使用github作为OAuth2认证服务器的配置文件 可以看到 accessTokenUri 和 userAuthorizationUri 都是为了完成OAuth2的授权流程所必须的配置，而 userInfoUri 则是spring security框架为了完成SSO所必须要的。所以总结一下就是： 通过将用户信息这个资源设置为被保护资源，可以使用OAuth2技术实现单点登陆（SSO），而Spring Security OAuth2就是这种OAuth2 SSO方案的一个实现。 Spring Security在调用user接口成功后，会构造一个 OAuth2Authentication 对象，这个对象是我们通常使用的 UsernamePasswordAuthenticationToken 对象的一个超集，里面封装了一个标准的 UsernamePasswordAuthenticationToken ，同时在 detail 中还携带了OAuth2认证中需要用到的一些关键信息（比如 tokenValue ， tokenType 等），这时候就完成了SSO的登陆认证过程。后续用户如果再想访问被保护资源，spring security只需要从principal中取出这个用户的token，再去访问资源服务器就行了，而不需要每次进行用户授权。这里要注意的一点是 此时浏览器与client之间仍然是通过传统的cookie-session机制来保持会话，而非通过token。实际上在SSO的过程中，使用到token访问的只有client与resource server之间获取user信息那一次，token的信息是保存在client的session中的，而不是在用户本地 。这也是之前我没搞清楚的地方，以为浏览器和client之间也是使用token，绕了不少弯路，对于Spring Security来说， 不管是用cas、saml2还是Oauth2来实现SSO，最后和用户建立会话保持的方式都是一样的 。 根据前面所说，大家不难看出，OAuth2的SSO方案和CAS、SAML2这样的纯SSO框架是有本质区别的。在CAS和SAML2中，没有资源服务器的概念，只有认证客户端（需要验证客户信息的应用）和认证服务器（提供认证服务的应用）的概念。在CAS中这叫做 cas-client 和 cas-server ，SAML2中这叫做 Service Providers 和 Identity Provider ，可以看出CAS、SAML2规范天生就是为SSO设计的，在报文结构上都考虑到了用户信息的问题（SAML2规范甚至还带了权限信息），而OAuth2本身不是专门为SSO设计的，主要是为了解决资源第三方授权访问的问题，所以在用户信息方面，还需要额外提供一个接口。 脸盆网的这个例子中，我们看到资源服务器和认证服务器是在一起的（都是facebook），在互联网场景下一般你很难找到一个独立的、权威的、第三方的认证中心（你很难想像腾讯的QQ空间通过支付宝的认证中心去授权，也很难想像使用谷歌服务要通过亚马逊去授权）。但是如果是在公司内部，这种场景其实是很多的，尤其在微服务架构下，有大量服务会对外提供资源访问，他们都需要做权限控制。那么最合理的当然就是建立一个统一的认证中心，而不是每个服务都做一个认证中心。我们前面也介绍了，token本身是不携带用户信息的，在分离后resouce server在收到请求后，如何检验token的真实性？又如何从token中获取对应的用户信息？这部分的介绍网上其实非常少，幸好我们可以直接从官方文档获取相关的蛛丝马迹，官方文档对于resouce server的配置是这样描述的： 寥寥数语，但已经足够我们分析了。从这个配置可以看出，client在访问resource server的被保护资源时，如果没有携带token，则资源服务器直接返回一个401未认证的错误 如果携带了token，则资源服务器会使用这个token向认证服务器发起一个用户查询的请求，若token错误或已经失效，则会返回 若token验证成功，则认证服务器向资源服务器返回对应的用户信息，此时resource server的spring security安全框架就可以按照标准的授权流程进行访问权限控制了。 从这个流程中我们可以看出，通过OAuth2进行SSO认证，有一个好处是做到了 认证与授权的解耦 。从日常的使用场景来说，认证比较容易做到统一和抽象，毕竟你就是你，走到哪里都是你，但是你在不同系统里面的角色，却可能千差万别（家里你是父亲，单位里你是员工，父母那里你是子女）。同时角色的设计，又是和资源服务器的设计强相关的。从前面的配置中不难发现，如果希望获得为不同资源服务器设计的角色，你只需要替换 https://api.facebook.com/user 这个配置就行了，这为我们的权限控制带来了更大的灵活性，而这是传统的比如SAML2这样的SSO框架做不到的。 终于来到了著名的JWT部分了，JWT全称为Json Web Token，最近随着微服务架构的流行而越来越火，号称新一代的认证技术。今天我们就来看一下，jwt的本质到底是什么。 我们先来看一下OAuth2的token技术有没有什么痛点，相信从之前的介绍中你也发现了，token技术最大的问题是 不携带用户信息 ，且资源服务器无法进行本地验证，每次对于资源的访问，资源服务器都需要向认证服务器发起请求，一是验证token的有效性，二是获取token对应的用户信息。如果有大量的此类请求，无疑处理效率是很低的，且认证服务器会变成一个中心节点，对于SLA和处理性能等均有很高的要求，这在分布式架构下是很要命的。 JWT就是在这样的背景下诞生的，从本质上来说，jwt就是一种 特殊格式 的token。普通的oauth2颁发的就是一串随机hash字符串，本身无意义，而jwt格式的token是有特定含义的，分为三部分： 这三部分均用base64进行编码，当中用 . 进行分隔，一个典型的jwt格式的token类似 xxxxx.yyyyy.zzzzz 。关于jwt格式的更多具体说明，不是本文讨论的重点，大家可以直接去官网查看 官方文档 ，这里不过多赘述。 相信看到签名大家都很熟悉了，没错，jwt其实并不是什么高深莫测的技术，相反非常简单。认证服务器通过对称或非对称的加密方式利用 payload 生成 signature ，并在 header 中申明签名方式，仅此而已。通过这种本质上极其传统的方式，jwt可以实现 分布式的token验证功能 ，即资源服务器通过事先维护好的对称或者非对称密钥（非对称的话就是认证服务器提供的公钥），直接在本地验证token，这种去中心化的验证机制无疑很对现在分布式架构的胃口。jwt相对于传统的token来说，解决以下两个痛点： 在上面的那个资源服务器和认证服务器分离的例子中，如果认证服务器颁发的是jwt格式的token，那么资源服务器就可以直接自己验证token的有效性并绑定用户，这无疑大大提升了处理效率且减少了单点隐患。 就像布鲁克斯在《人月神话》中所说的名言一样：“没有银弹”。JWT的使用上现在也有一种误区，认为传统的认证方式都应该被jwt取代。事实上，jwt也不能解决一切问题，它也有适用场景和不适用场景。 适用场景： 这些场景能充分发挥jwt无状态以及分布式验证的优势 不适用的场景： 不要试图用jwt去代替session。 这种模式下其实传统的session+cookie机制工作的更好，jwt因为其无状态和分布式，事实上只要在有效期内，是无法作废的，用户的签退更多是一个客户端的签退，服务端token仍然有效，你只要使用这个token，仍然可以登陆系统。另外一个问题是续签问题，使用token，无疑令续签变得十分麻烦，当然你也可以通过redis去记录token状态，并在用户访问后更新这个状态，但这就是硬生生把jwt的无状态搞成有状态了，而这些在传统的session+cookie机制中都是不需要去考虑的。这种场景下，考虑高可用，我更加推荐采用分布式的session机制，现在已经有很多的成熟框架可供选择了（比如spring session）。

JWT表示公司字头，JWT8.000即：晶威特电子有限公司产品 频率为8.000MHz的晶振

JWT里有一个关键的东东,就是续期TOKEN,即TOKEN快过期时,刷新一个新的TOKEN给客户端. 办法如下: 1.后端生成TOKEN 原签发TOKEN后10分钟后刷新新的TOKEN 2.前端获取TOKEN 注意一点,需要通过过滤器调整FITLER,增加Access-Control-Expose-Headers的输出,否则无法获取response中的header. 至此,JWT的TOKEN续期功能完成.

在jwt文件的头文件中可以看token文件失效，Token在计算机身份认证中是令牌（临时）的意思，在词法分析中是标记的意思。一般作为邀请、登录系统使用。

这个库已经没人维护了，他们现在新搞了一个，具体可以去github上看 jwt(json web token)是一种用于前后端身份认证的方法,一个jwt由header，payload，和signature组成。 1.Claims claims是一个实现了Valid方法的interface，Valid方法用于判断该claim是否合法 2.Keyfunc Keyfunc在使用时一般都是返回secret密钥，可以根据Token的种类不同返回不同的密钥. 官方文档:This allows you to use properties in the Header of the token (such as "kid") to identify which key to use. 3.Mapclaims 一个用于放decode出来的claim的map,有Vaild和一系列VerifyXXX的方法 4.Parser 用来将tokenstr转换成token 5.SigningMethod 签名方法的接口，可以通过实现这个接口自定义签名方法，jwt-go内置一些实现了SigningMethod的结构体 6.StandardClaims jwt官方规定的一些预定义的payload: 7.Token Token的结构体 8.ValidationError 定义解析Token时遇到的一些错误 首先我们先来看Parse() 实际上是调用了ParseWithClaims,第二个参数就是一个map[string]interface,这个函数的源码如下,这个函数内部调用的ParseUnverified,我们先来看看这个函数 官方的解释是，这个函数不校验签名的有效性，只单纯负责把tokenStr变成Token对象，而之后的事情就是交给ParseWithClaims来做啦 可以看到，ParseUnverified这个方法真的只是单纯的解码Header段和Claim段，然后检查一下用的alg是不是合法，就返回了，让我们继续往下看验证的逻辑 ok,关于解析token的主要方法我们已经看完了，接下来我们来看看如何生成一个token，其实就是反着操作一遍 先看New函数，选择一种SigningMethod，新建一个token，内部调用NewWithClaims 再看NewWithClaims,发现就是简单的给JwtToken的三个部分赋值 最后是SignedString，即使用alg的算法给token加密，生成最终的tokenStr,内部调用了SigningString，所以先看SigningString 发现SigningString就是把token的头部先变成json然后base64url编码，但是没有生成jwtToken的最后一个部分 所以SignedString作用就是用给定的加密方法和你的SecretKey对前面两部分加密，添在token的最后一段，至此token生成完毕

第二个错了，少了个负号。不过这里的i和j都是虚数单位，一般情况下（四元数除外）可以互换。

您好，想要知道他单点登录的一些原理的话，那么其实是需要学习的。或者也可以问一下吧，不知道你能不能够理解。

具体如下。最简单方便，直接修改请求头中的key值就可以了，我是将keyApp_Token修改成App-Token就可以正常获取了。去掉Nginx的限制，在Nginx里的nginx.conf配置文件中的http部分将nderscores_in_headers默认的off修改为如果原本没有就直接添加underscores_in_headerson;即可。：token需要查库验证token是否有效，而JWT不用查库或者少查库，直接在服务端进行校验，并且不用查库。服务端验证客户端发送的token信息要进行数据的查询操作Jwt验证客户端发来的token就不用，在服务端使用密钥校验就可以，不用数据库的查询。

启动项目时，SpringBoot自动检索所有带@Configuration的注解，所以就将我们的WebSecurityConfig给加载了，这个config中，我们需要在configure(AuthenticationManagerBuilder auth)方法中注册一个继承自UserDetailsService的接口，这个接口中只有一个方法，那就是使用username获取到数据库中用户信息并返回成UserDetail实体。这个方法需要我们按照我们的不同业务场景重写 WebSecurityConfig MyUserDetailsService 其实如果去掉上面的将自定义的JWT过滤器加入到过滤链中的话，这个认证过程已经完成了。使用下面的代码就可以调用起整个认证程序。 核心代码 这一行就会将username和password放到认证程序中进行认证。 也就是需要我们自己的逻辑让他去触发这个代码的实现。就可以自动完成认证程序了。就会触发使用username获取到数据库用户信息，然后经过密码加密比对之后会将认证结果返回。 我们整合JWT其实也很简单，其实就是将JWT的登录部分的操作，使用过滤器封装，将该过滤器放到整个认证的过滤链中 SpringSecurity过滤器的配置无非以下几个条件 先解决逻辑上以上三个问题的答案 针对以上解答，下面用代码来做展示（ps:序号依次对应上面） 完成了以上的配置，前台就可以使用/login/user来进行登录操作了。登录成功会返回一个JSON对象来供前端判断成功与否 全部代码奉上，随意写的注释有点多，不看的可以给删掉

在原先dubbo+zookeeper项目中，web模块只暴露Restful接口，各服务模块只暴露duboo接口，此时用户登录后由web项目进行token的鉴权和验证，并通过dubbo的隐式传参将sessionID传递给dubbo服务模块, 拦截器再根据sessionID从Redis中获取用户信息设置到当前线程 然鹅，在springcloud中，各个微服务直接暴露的是restful接口，此时如何让各个微服务获取到当前用户信息呢？最佳的方式就是token了，token作为BS之间的会话标识（一般是原生随机token），同时也可以作为信息的载体传递一些自定义信息（jwt， 即Json web token）。 为了能更清楚的了解本文，需要对spring-security-oauth 及 jwt有一定了解，本文只关注用户信息传递这一块 认证服务器配置 AuthorizationServerConfigurerAdapter 自定义token转换器 CustomJwtAccessTokenConverter 此时按照固定格式访问授权服务器token接口获取token，如图，可以获取到jwt格式的token，并且额外信息nick_name也已经添加 直接解析jwt字符串可以获取到以下信息，即用户名和授权信息 只需要指定和授权服务器一模一样的token store 和token converter 在securiy的过滤器中 OAuth2AuthenticationProcessingFilter 会从token中获取相关信息进行鉴权 源码： 注意，资源服务器主要配置在 ResourceServerConfigurerAdapter 微服务获取jwttoken中的用户信息，两种方式，使用security上下文可以直接获取当前用户名和权限，另一种自定义拦截器获取额外信息。 这个就简单了，获取header头解析验证token 然后获取之前从授权服务器中的添加的 nick_name的额外信息放入线程变量 其中用户上下文类 启动拦截器注册webmvc配置类 在controller中获取用户信息如图 在默认的认证异常如图 假设我们做了全局异常处理，前端希望在token过期时做统一的登录跳转如何做？ 实现 AuthenticationEntryPoint 接口重写 commence 方法即可 注意，直接抛出异常并不会走 @RestControllerAdvice , 因为在这里是response直接返回，并没有使用到Controller处理 此时返回我自定义的Response对象，如图

不是一回事shiro是一套权限管理框架，包括认证、授权等，在使用时直接写相应的接口就可以了，已经把底层处理都写好了而jwt只是一种生成token的机制，所有权限处理逻辑还需要自己写

JWT全称“JSON Web Token”，是基于JSON的用户身份认证的令牌。可跨域身份认证，所以JWT很适合做分布式的鉴权，单点登录（SingleSign,SSO）。 jwt有三部分组成用符号"."隔开， HEADER：token头，描述token是什么类型，加密方式是什么，把json内容转为base64 PAYLOAD:内容，是暴露出来的信息，不可存敏感信息,把json内容转为base64 SIGNATURE:签名，按token头的加密方式把HEADER和PAYLOAD的信息加密生成签名，下面是官网上面的介绍，地址： https://jwt.io/ jwt的token是不可以篡改的，虽然前两部分的内容可以base64解码之后就能看到明文，但由于第三部分签名是把前两部分内容用一个密钥加密的，验证的时候也是把前两部分内容再次加密和原来签名对比是否一致，若内容被篡改了，则两次签名不一致校验不通过。 问题一：同一个公司的系统 ，不如果每个系统都有一套自己的用户名密码，那用户记 得头都大了啊。所以这时产生了一个鉴权中心，全部系统用同一套用户信息，同一个地方登录。 问题二：用同一套用户信息可以了，但如果进每个系统都要输一次账户密码登录还是很麻烦的。所以这里还要一处登录 ，处处登录，登录了其中一个系统，进入其它系统的时候不需要登录 效果如下图所示 用户在sso中心登录后的token在站点A，站点B都能使用，并且站点A，站点B和sso中心不需要通讯也能自己鉴别token是否是有效的。 怎么做到站点和sso串联呢？具体的流程是用户打开站点A，发现未登录 ，那站点A会跳转到sso中心登录并且把自己的url带上，sso中心登录成功后，跳转回站点带过来的url并把token也带上。 那站点A登录成功了，站点B怎么共享这个Token呢，做法是，sso中心登录成功的时候同时存一份Token到cookie(或localstorage等地方)，当用户进入站点B的时候，发现没登录，跳转到sso中心带上自己的url，sso中心发现cookie有token了，直接跳转回站点B的url并把token带上，这样站点B就能实现token共享和自动登录了。 新建一个AuthenticationCenter项目 新建一个AuthenticatinController控制器 Login的view视图 其它相关类 上面sso的登录功能就完成了，打开Login页面就能获取到Token了。 新建一个站点A 修改startup.cs文件，在ConfigureServices方法里加上 在Configure方法里加上 新建一个UserController 其它相关类 密钥要和sso中心的保持一致，上面的5000端口是sso的端口，27271端口是站点端口。

1、JWT的构成 - 头部(header):描述该JWT的最基本的信息，如类型以及签名所用的算法。 - 负载(payload):存放有效信息的地方。 - 签证(signature):base64加密后的header、base64加密后的payload和密钥secret加密后组成。 2、整合JWT 2.1 引入JWT依赖 com.auth0 java-jwt 3.18.3 2.2 编写JWTUtils工具类 package com.stock.utils; import com.auth0.jwt.JWT; import com.auth0.jwt.JWTCreator; import com.auth0.jwt.JWTVerifier; import com.auth0.jwt.algorithms.Algorithm; import com.auth0.jwt.interfaces.DecodedJWT; import com.auth0.jwt.interfaces.Verification; import java.util.Calendar; import java.util.Map; public class JWTUtils { private static final String SING="@#$%^&*"; // 生成token public static String getToken(Map map){ Calendar instance = Calendar.getInstance(); instance.add(Calendar.MINUTE,30); //创建jwt builder JWTCreator.Builder builder = JWT.create(); //payload builder.withExpiresAt(instance.getTime()); map.forEach((k,v)->{ builder.withClaim(k,v); }); //设置签名 String token = builder.sign(Algorithm.HMAC256(SING)); return token; } //验证令牌 public static void verifyToken(String token){ JWTVerifier require = JWT.require(Algorithm.HMAC256(SING)).build(); require.verify(token); } //获取token信息 public static DecodedJWT getTokenInfo(String token){ DecodedJWT verify = JWT.require(Algorithm.HMAC256(SING)).build().verify(token); return verify; } } 2.3 编写拦截器 public class JWTInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (HttpMethod.OPTIONS.toString().equals(request.getMethod())) { System.out.println("OPTIONS请求，放行"); return true; } HashMap map = new HashMap>(); String token = request.getHeader("token"); try { JWTUtils.verifyToken(token); return true; }catch (SignatureVerificationException e){ map.put("msg","无效签名!"); }catch (TokenExpiredException e){ map.put("msg","token过期!"); }catch (AlgorithmMismatchException e){ map.put("msg","token加密算法不一致"); }catch (Exception e){ map.put("msg","无效签名!"); } map.put("state",404); map.put("path","/login"); //将map转化为字符串返回给前端 String result = new ObjectMapper().writeValueAsString(map); response.setContentType("application/json;charset=UTF-8"); response.getWriter().println(result); return false; } } 注意： 1、token存放在请求的header中； 2、在前后端分离的项目中，发送的GET/POST请求实则为两次请求。第一次请求为OPTIONS请求，第二次请求才是GET/POST请求；在OPTIONS请求中，不会携带请求头的参数，会导致在拦截器上获取请求头为空，自定义的拦截器拦截成功。第一次请求不能通过，就不能获取第二次的请求。所以需要在拦截器中加上如下代码来判断是否为OPTIONS请求，对于OPTIONS请求直接放过。 if (HttpMethod.OPTIONS.toString().equals(request.getMethod())) { System.out.println("OPTIONS请求，放行"); return true; } 2.4 配置拦截器 package com.stock.config; import com.stock.Interceptors.JWTInterceptor; import org.springframework.context.annotation.Configuration; import org.springframework.web.servlet.config.annotation.InterceptorRegistry; import org.springframework.web.servlet.config.annotation.WebMvcConfigurer; @Configuration public class IntercepterConfg implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new JWTInterceptor()) .addPathPatterns("/**") .excludePathPatterns("/login"); } } 2.5 编写Controller package com.stock.controller; import com.stock.entity.User; import com.stock.result.Result; import com.stock.service.UserService; import com.stock.utils.JWTUtils; import com.stock.utils.ResultUtils; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.PostMapping; import org.springframework.web.bind.annotation.RequestBody; import org.springframework.web.bind.annotation.RestController; import java.util.HashMap; @RestController public class LoginController { private UserService userService; @Autowired public LoginController(UserService userService) { this.userService = userService; } @PostMapping("/login") public Result register(User user){ HashMap map = new HashMap>(); map.put("username",user.getUserName()); String token = JWTUtils.getToken(map); HashMap data = new HashMap>(); data.put("token",token); return ResultUtils.getresult(200,"登录成功!",data); } @GetMapping("/main") public Result tomain(){ return ResultUtils.getresult(200,"访问成功",null); } } 2.6使用Postman测试 - 未登录前访问127.0.0.1:8888/main - 先登录再访问127.0.0.1:8888/main

15天。前端发起请求，后端验证token（A）是否过期；如果过期，前端发起刷新token请求，后端设置已再次授权标记为true，请求成功前端发起请求，后端验证再次授权标记，如果已经再次授权，则拒绝刷新token的请求，请求成功，如果前端每隔72小时，必须重新登录，后端检查用户最后一次登录日期，如超过72小时，则拒绝刷新token的请求，请求失败。

前后端分离架构带来的好处一搜一大堆，我们来看一下分离后后端接口的安全问题。 前后端分离架构现状： 这样的情况后端api是暴露在外网中，因为常规的web项目无论如何前端都是要通过公网访问到后台api的，带来的隐患也有很多。 1.接口公开，谁都可以访问 2.数据请求的参数在传输过程被篡改 3.接口被重复调用 ... session和cookie都是客户端与服务端通讯需要提供的认证，当客户端的值和服务器的值吻合时，才允许请求api，解决了第1个问题，但是当攻击者获取到了传输过程中的session或者cookie值后，就可以进行第2、3种攻击了 JWT标准的token包含三部分： 头部用于描述关于该JWT的最基本的信息，例如其类型以及签名所用的算法等 将上面的JSON对象进行 [base64编码] 可以得到下面的字符串。这个字符串我们将它称作JWT的Header Payload也是一个JSON对象。包含了一些其他的信息 这里面的前五个字段都是由JWT的标准所定义的。 将上面的JSON对象进行 [base64编码] 可以得到下面的字符串。这个字符串我们将它称作JWT的Payload 将上面的两个编码后的字符串都用句号 . 连接在一起（头部在前），就形成了 最后，我们将上面拼接完的字符串用 HS256算法 进行加密。在加密的时候，我们还需要提供一个 密钥（secret） 。如果我们用 mystar 作为密钥的话，那么就可以得到我们加密后的内容 这一部分叫做 签名 最后将这一部分签名也拼接在被签名的字符串后面，我们就得到了完整的JWT 签名解决了数据传输过程中参数被篡改的风险 一般而言，加密算法对于不同的输入产生的输出总是不一样的，如果有人 对Header以及Payload的内容解码之后进行修改，再进行编码的话，那么新的头部和载荷的签名和之前的签名就将是不一样的。 而且，如果不知道服务器加密的时候用的密钥的话，得出来的签名也一定会是不一样的。 解决了篡改数据的问题，还有第3个问题，那就是攻击者不修改数据，只是重复攻击 比如在浏览器端通过用户名/密码验证获得签名的Token被木马窃取。即使用户登出了系统，黑客还是可以利用窃取的Token模拟正常请求，而服务器端对此完全不知道， 因为JWT机制是无状态的。 可以在Payload里增加时间戳并且前后端都参与来解决：

什么是JWT pom.xml JWTUtil.java 用户登录操作 在前后分离场景下，越来越多的项目使用jwt token作为接口的安全机制,但存在jwt过期后，用户无法直接感知，假如在用户操作页面期间，突然提示登录，则体验很不友好，所以就有了token自动刷新需求； 方案：前端控制检测token，无感知刷新 用户登录成功的时候，一次性给他两个Token，分别为AccessToken和RefreshToken AccessToken有效期较短,比如1天或者5天，用于正常请求 RefreshToken有效期可以设置长一些，例如10天、20天，作为刷新AccessToken的凭证 刷新方案：当AccessToken即将过期的时候，例如提前30分钟，客户端利用RefreshToken请求指定的API获取新的AccessToken并更新本地存储中的AccessToken 核心逻辑 1、登录成功后，jwt生成AccessToken； UUID生成RefreshToken并存储在服务端redis中,设置过期时间 2、接口返回3个字段AccessToken/RefreshToken/访问令牌过期时间戳 3、由于RefreshToken存储在服务端redis中，假如这个RefreshToken也过期，则提示重新登录； 老王的疑问：RefreshToken有效期那么长，和直接将AccessToken的有效期延长有什么区别 答：RefreshToken不像AccessToken那样在大多数请求中都被使用，主要是本地检测accessToken快过期的时候才使用， 一般本地存储的时候，也不叫refreshToken,前端可以取个别名，混淆代码让攻击者不能直接识别这个就是刷新令牌 缺点：前端每次请求需要判断token距离过期时间 优点：后端压力小，代码逻辑改动不大 刷新token方法未实现。

本文适合： 对Spring Security有一点了解或者跑过简单demo但是对整体运行流程不明白的同学，对SpringSecurity有兴趣的也可以当作你们的入门教程，示例代码中也有很多注释。 大家在做系统的时候，一般做的第一个模块就是 认证与授权 模块，因为这是一个系统的入口，也是一个系统最重要最基础的一环，在认证与授权服务设计搭建好了之后，剩下的模块才得以安全访问。 市面上一般做认证授权的框架就是shiro和Spring Security，也有大部分公司选择自己研制。出于之前看过很多Spring Security的入门教程，但都觉得讲的不是太好，所以我这两天在自己鼓捣Spring Security的时候萌生了分享一下的想法，希望可以帮助到有兴趣的人。 Spring Security框架我们主要用它就是解决一个认证授权功能，所以我的文章主要会分为两部分： 我会为大家用一个Spring Security + JWT + 缓存的一个demo来展现我要讲的东西，毕竟脑子的东西要体现在具体事物上才可以更直观的让大家去了解去认识。 学习一件新事物的时候，我推荐使用自顶向下的学习方法，这样可以更好的认识新事物，而不是盲人摸象。 注 ：只涉及到用户认证授权不涉及oauth2之类的第三方授权。 想上手 Spring Security 一定要先了解它的工作流程，因为它不像工具包一样，拿来即用，必须要对它有一定的了解，再根据它的用法进行自定义操作。 我们可以先来看看它的工作流程： 在Spring Security的官方文档上有这么一句话： Spring Security 的web基础是Filters。 这句话展示了Spring Security的设计思想： 即通过一层层的Filters来对web请求做处理。 放到真实的Spring Security中，用文字表述的话可以这样说: 一个web请求会经过一条过滤器链，在经过过滤器链的过程中会完成认证与授权，如果中间发现这条请求未认证或者未授权，会根据被保护API的权限去抛出异常，然后由异常处理器去处理这些异常。 用图片表述的话可以这样画，这是我在百度找到的一张图片： 如上图，一个请求想要访问到API就会以从左到右的形式经过蓝线框框里面的过滤器，其中绿色部分是我们本篇主要讲的负责认证的过滤器，蓝色部分负责异常处理，橙色部分则是负责授权。 图中的这两个绿色过滤器我们今天不会去说，因为这是Spring Security对form表单认证和Basic认证内置的两个Filter，而我们的demo是JWT认证方式所以用不上。 如果你用过Spring Security就应该知道配置中有两个叫formLogin和httpBasic的配置项，在配置中打开了它俩就对应着打开了上面的过滤器。 换言之，你配置了这两种认证方式，过滤器链中才会加入它们，否则它们是不会被加到过滤器链中去的。 因为Spring Security自带的过滤器中是没有针对JWT这种认证方式的，所以我们的demo中会 写一个JWT的认证过滤器，然后放在绿色的位置进行认证工作。 知道了Spring Security的大致工作流程之后，我们还需要知道一些非常重要的概念也可以说是组件： 上下文对象，认证后的数据就放在这里面，接口定义如下： 这个接口里面只有两个方法，其主要作用就是get or set Authentication。 可以说是SecurityContext的工具类，用于get or set or clear SecurityContext，默认会把数据都存储到当前线程中。 这几个方法效果如下： Authentication只是定义了一种在SpringSecurity进行认证过的数据的数据形式应该是怎么样的，要有权限，要有密码，要有身份信息，要有额外信息。 AuthenticationManager定义了一个认证方法，它将一个未认证的Authentication传入，返回一个已认证的Authentication，默认使用的实现类为：ProviderManager。 接下来大家可以构思一下如何将这四个部分，串联起来，构成Spring Security进行认证的流程： 1. 先是一个请求带着身份信息进来 2. 经过AuthenticationManager的认证， 3. 再通过SecurityContextHolder获取SecurityContext， 4. 最后将认证后的信息放入到SecurityContext。 真正开始讲诉我们的认证代码之前，我们首先需要导入必要的依赖，数据库相关的依赖可以自行选择什么JDBC框架，我这里用的是国人二次开发的myabtis-plus。 接着，我们需要定义几个必须的组件。 由于我用的Spring-Boot是2.X所以必须要我们自己定义一个加密器： 这个Bean是不必可少的，Spring Security在认证操作时会使用我们定义的这个加密器，如果没有则会出现异常。 实现UserDetailsService的抽象方法并返回一个 UserDetails 对象，认证过程中SpringSecurity会调用这个方法访问数据库进行对用户的搜索，逻辑什么都可以自定义，无论是从数据库中还是从缓存中，但是我们需要将我们查询出来的用户信息和权限信息组装成一个 UserDetails 返回。 UserDetails 也是一个定义了数据形式的接口，用于保存我们从数据库中查出来的数据，其功能主要是验证账号状态和获取权限，具体实现可以查阅我仓库的代码。 由于我们是JWT的认证模式，所以我们也需要一个帮我们操作Token的工具类，一般来说它具有以下三个方法就够了： 在下文我的代码里面，JwtProvider充当了Token工具类的角色，具体实现可以查阅我仓库的代码。 有了前面的讲解之后，大家应该都知道用SpringSecurity做JWT认证需要我们自己写一个过滤器来做JWT的校验，然后将这个过滤器放到绿色部分。 在我们编写这个过滤器之前，我们还需要进行一个认证操作，因为我们要先访问认证接口拿到token，才能把token放到请求头上，进行接下来请求。 如果你不太明白，不要紧，先接着往下看我会在这节结束再次梳理一下。 访问一个系统，一般最先访问的是认证方法，这里我写了最简略的认证需要的几个步骤，因为实际系统中我们还要写登录记录啊，前台密码解密啊这些操作。 这里一共五个步骤，大概只有前四步是比较陌生的： 这样的话就算完成了，感觉上很简单，因为主要认证操作都会由authenticationManager.authenticate()帮我们完成。 接下来我们可以看看源码，从中窥得Spring Security是如何帮我们做这个认证的（省略了一部分）： 看了源码之后你会发现和我们平常写的一样，其主要逻辑也是查数据库然后对比密码。 登录之后效果如下： 我们返回token之后，下次请求其他API的时候就要在请求头中带上这个token，都按照JWT的标准来做就可以。 有了token之后，我们要把过滤器放在过滤器链中，用于解析token，因为我们没有session，所以我们每次去辨别这是哪个用户的请求的时候，都是根据请求中的token来解析出来当前是哪个用户。 所以我们需要一个过滤器去拦截所有请求，前文我们也说过，这个过滤器我们会放在绿色部分用来替代UsernamePasswordAuthenticationFilter，所以我们新建一个JwtAuthenticationTokenFilter，然后将它注册为Bean，并在编写配置文件的时候需要加上这个： addFilterBefore的语义是添加一个Filter到XXXFilter之前，放在这里就是把JwtAuthenticationTokenFilter放在UsernamePasswordAuthenticationFilter之前，因为filter的执行也是有顺序的，我们必须要把我们的filter放在过滤器链中绿色的部分才会起到自动认证的效果。 接下来我们可以看看JwtAuthenticationTokenFilter的具体实现了： 代码里步骤虽然说的很详细了，但是可能因为代码过长不利于阅读，我还是简单说说，也可以直接去仓库查看源码： 这样的话，每一个带有正确token的请求进来之后，都会找到它的账号信息，并放在上下文对象中，我们可以使用SecurityContextHolder很方便的拿到上下文对象中的Authentication对象。 完成之后，启动我们的demo，可以看到过滤器链中有以下过滤器，其中我们自定义的是第5个： 就酱，我们登录完了之后获取到的账号信息与角色信息我们都会放到缓存中，当带着token的请求来到时，我们就把它从缓存中拿出来，再次放到上下文对象中去。 结合认证方法，我们的逻辑链就变成了： 登录拿到token请求带上tokenJWT过滤器拦截校验token将从缓存中查出来的对象放到上下文中 这样之后，我们认证的逻辑就算完成了。 认证和JWT过滤器完成后，这个JWT的项目其实就可以跑起来了，可以实现我们想要的效果，如果想让程序更健壮，我们还需要再加一些辅助功能，让代码更友好。 当用户未登录或者token解析失败时会触发这个处理器，返回一个非法访问的结果。 当用户本身权限不满足所访问API需要的权限时，触发这个处理器，返回一个权限不足的结果。 用户退出一般就是清除掉上下文对象和缓存就行了，你也可以做一下附加操作，这两步是必须的。 JWT的项目token刷新也是必不可少的，这里刷新token的主要方法放在了token工具类里面，刷新完了把缓存重载一遍就行了，因为缓存是有有效期的，重新put可以重置失效时间。 这篇文我从上周日就开始构思了，为了能讲的老妪能解，修修改改了几遍才发出来。 作者：和耳朵 链接：https://juejin.cn/post/6846687598442708999

业务场景 在前后分离场景下，越来越多的项目使用token作为接口的安全机制，APP端或者WEB端（使用VUE、REACTJS等构建）使用token与后端接口交互，以达到安全的目的。本文结合stackover以及本身项目实践，试图总结出一个通用的，可落地的方案。 基本思路 用户仅登录一次，用户改变密码，则废除token，重新登录 1.0实现 1.登录成功，返回access_token和refresh_token，客户端缓存此两种token;2.使用access_token请求接口资源，成功则调用成功；如果token超时，客户端携带refresh_token调用中间件接口获取新的access_token;3.中间件接受刷新token的请求后，检查refresh_token是否过期。如过期，拒绝刷新，客户端收到该状态后，跳转到登录页；如未过期，生成新的access_token和refresh_token并返回给客户端（如有可能，让旧的refresh_token失效），客户端携带新的access_token重新调用上面的资源接口。4.客户端退出登录或修改密码后，调用中间件注销旧的token(使access_token和refresh_token失效)，同时清空客户端的access_token和refresh_toke。 后端表id user_id client_id client_secret refresh_token expire_in create_date del_flag 2.0实现 场景： access_token访问资源 refresh_token授权访问 设置固定时间X必须重新登录 1.登录成功，后台jwt生成access_token（jwt有效期30分钟）和refresh_token（jwt有效期15天），并缓存到redis（hash-key为token,sub-key为手机号,value为设备唯一编号（根据手机号码，可以人工废除全部token，也可以根据sub-key,废除部分设备的token。），设置过期时间为1个月，保证最终所有token都能删除)，返回后，客户端缓存此两种token;2.使用access_token请求接口资源，校验成功且redis中存在该access_token（未废除）则调用成功；如果token超时，中间件删除access_token（废除）；客户端再次携带refresh_token调用中间件接口获取新的access_token;3.中间件接受刷新token的请求后，检查refresh_token是否过期。如过期，拒绝刷新，删除refresh_token（废除）； 客户端收到该状态后，跳转到登录页；如未过期，检查缓存中是否有refresh_token（是否被废除），如果有，则生成新的access_token并返回给客户端，客户端接着携带新的access_token重新调用上面的资源接口。4.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token和refresh_token（废除）)，同时清空客户端侧的access_token和refresh_toke。5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。6.以上3刷新access_token可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：失效，长时间未登录，频繁刷新） 2.0 变动1.登录2.登录拦截器3.增加刷新access_token接口4.退出登录5.修改密码 3.0实现 场景：自动续期 长时间未使用需重新登录 1.登录成功，后台jwt生成access_token（jwt有效期30分钟），并缓存到redis（hash-key为access_token,sub-key为手机号,value为设备唯一编号（根据手机号码，可以人工废除全部token），设置access_token过期时间为7天，保证最终所有token都能删除)，返回后，客户端缓存此token; 2.使用access_token请求接口资源，校验成功且redis中存在该access_token（未废除）则调用成功；如果token超时，中间件删除access_token（废除）,同时生成新的access_token并返回。客户端收到新的access_token，再次请求接口资源。 3.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token（废除）)，同时清空客户端侧的access_token。 4.以上2 可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：长时间未登录，频繁刷新） 5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。 3.0 变动 1.登录2.登录拦截器3.退出登录4.修改密码 1.3 场景：token过期重新登录 长时间未使用需重新登录 1.登录成功，后台jwt生成access_token（jwt有效期7天），并缓存到redis，key为 "user_id:access_token",value为access_token（根据用户id，可以人工废除指定用户全部token），设置缓存过期时间为7天，保证最终所有token都能删除，请求返回后，客户端缓存此access_token； 2.使用access_token请求接口资源，校验成功且redis中存在该access_token（未废除）则调用成功；如果token超时，中间件删除access_token（废除）,同时生成新的access_token并返回。客户端收到新的access_token，再次请求接口资源。 3.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token（废除）)，同时清空客户端侧的access_token。 4.以上2 可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：长时间未登录，频繁刷新） 5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。 1.3 变动 1.登录2.登录拦截器3.退出登录4.修改密码 2.0 场景： access_token访问资源 refresh_token授权访问 设置固定时间X必须重新登录 1.登录成功，后台jwt生成access_token（jwt有效期30分钟）和refresh_token（jwt有效期15天），并缓 存到redis（hash-key为token,sub-key为手机号,value为设备唯一编号（根据手机号码，可以人工废除全 部token，也可以根据sub-key,废除部分设备的token。），设置过期时间为1个月，保证最终所有token都 能删除)，返回后，客户端缓存此两种token; 2.使用access_token请求接口资源，校验成功且redis中存在该access_token（未废除）则调用成功；如果 token超时，中间件删除access_token（废除）；客户端再次携带refresh_token调用中间件接口获取新的 access_token; 3.中间件接受刷新token的请求后，检查refresh_token是否过期。 如过期，拒绝刷新，删除refresh_token（废除）； 客户端收到该状态后，跳转到登录页； 如未过期，检查缓存中是否有refresh_token（是否被废除），如果有，则生成新的access_token并返回给 客户端，客户端接着携带新的access_token重新调用上面的资源接口。 4.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token和refresh_token（ 废除）)，同时清空客户端侧的access_token和refresh_toke。 5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。 6.以上3刷新access_token可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（ 拒绝的场景：失效，长时间未登录，频繁刷新） 2.0 变动 1.登录 2.登录拦截器 3.增加刷新access_token接口 4.退出登录 5.修改密码 3.0 场景：自动续期 长时间未使用需重新登录 1.登录成功，后台jwt生成access_token（jwt有效期30分钟），并缓存到redis（hash-key为 access_token,sub-key为手机号,value为设备唯一编号（根据手机号码，可以人工废除全部token，也可以 根据sub-key,废除部分设备的token。），设置access_token过期时间为1个月，保证最终所有token都能删 除)，返回后，客户端缓存此token; 2.使用access_token请求接口资源，校验成功且redis中存在该access_token（未废除）则调用成功；如果 token超时，中间件删除access_token（废除）,同时生成新的access_token并返回。客户端收到新的 access_token， 再次请求接口资源。 3.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token（废除）)，同时清 空客户端侧的access_token。 4.以上2 可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：长 时间未登录，频繁刷新） 5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。 3.0 变动 1.登录 2.登录拦截器 3.退出登录 4.修改密码 4.0 场景：token过期重新登录 长时间未使用需重新登录 1.登录成功，后台jwt生成access_token（jwt有效期7天），并缓存到redis，key为 "user_id:access_token" + 用户id,value为access_token（根据用户id，可以人工废除指定用户全部 token），设置缓存过期时间为7天，保证最终所有token都能删除，请求返回后，客户端缓存此 access_token； 2.使用access_token请求接口资源，校验成功且redis中存在该access_token（未废除）则调用成功；如果 token超时，中间件删除access_token（废除）,同时生成新的access_token并返回。客户端收到新的 access_token， 再次请求接口资源。 3.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token（废除）)，同时清 空客户端侧的access_token。 4.以上2 可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：长 时间未登录，频繁刷新） 5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。 4.0 变动 1.登录 2.登录拦截器 3.退出登录 4.修改密码 最终实现 后端

这次给大家带来Koa实现JWT用户认证需要哪些步骤，Koa实现JWT用户认证的注意事项有哪些，下面就是实战案例，一起来看一下。一、前置知识基于Token的身份验证Koajs 中文文档Koa 框架教程二、环境Microsoft Visual Studio 2017集成开发环境Node.js v8.9.4Javascript运行环境三、开始动手，一步步来完善1、创建基础的静态资源服务器、基础架构以下是基本的代码，实现静态服务器，以及一个当token验证异常时候的处理。下面我们将在这个基本代码下逐步增加注册、登录、信息的功能。const path = require("path"); // 用于处理目录路径const Koa = require("koa"); // web开发框架const serve = require("koa-static"); // 静态资源处理const route = require("koa-route"); // 路由中间件const jwt = require("jsonwebtoken"); // 用于签发、解析`token`const jwtKoa = require("koa-jwt"); // 用于路由权限控制const koaBody = require("koa-body"); // 用于查询字符串解析到`ctx.request.query`const app = new Koa();const website = { scheme: "http", host: "localhost", port: 1337, join: function () { return `${this.scheme}://${this.host}:${this.port}` }}/* jwt密钥 */const secret = "secret";/* 当token验证异常时候的处理，如token过期、token错误 */app.use((ctx, next) => { return next().catch((err) => { if (err.status === 401) { ctx.status = 401; ctx.body = { ok: false, msg: err.originalError ? err.originalError.message : err.message } } else { throw err; } });});/* 查询字符串解析到`ctx.request.query` */app.use(koaBody());/* 路由权限控制 */// 待办事项??/* POST /api/register 注册 */// 待办事项??/* GET /api/login 登录 */// 待办事项??/* GET /api/info 信息 */// 待办事项??/* 静态资源处理 */app.use(serve(path.join(dirname, "static")));/* 监听服务器端口 */app.listen(website.port, () => { console.log(`${website.join()} 服务器已经启动！`);});下面，我们将在注册、登录、信息的注释底下添加实现的代码。2、路由权限控制注册、登录接口、其它资源不需要认证，信息接口需要认证。/* 路由权限控制 */app.use(jwtKoa({ secret: secret }).unless({ // 设置login、register接口，可以不需要认证访问 path: [ /^/api/login/, /^/api/register/, /^((?!/api).)*$/ // 设置除了私有接口外的其它资源，可以不需要认证访问 ]}));3、注册/* POST /api/register 注册 */app.use(route.post("/api/register", async (ctx, next) => { const body = ctx.request.body; /* * body = { * user : "御焱", * password : "123456" * } */ // 判断 body.user 和 body.password 格式是否正确 // 待办事项?? // 判断用户是否已经注册 // 待办事项?? // 保存到新用户到数据库中 // 待办事项?? // 是否注册成功 let 是否注册成功 = true; if (是否注册成功) { // 返回一个注册成功的JOSN数据给前端 return ctx.body = { ok: true, msg: "注册成功", token: getToken({ user: body.user, password: body.password }) } } else { // 返回一个注册失败的JOSN数据给前端 return ctx.body = { ok: false, msg: "注册失败" } }}));/* 获取一个期限为4小时的token */function getToken(payload = {}) { return jwt.sign(payload, secret, { expiresIn: "4h" });}3、登录/* GET /api/login 登录 */app.use(route.get("/api/login", async (ctx, next) => { const query = ctx.request.query; /* * query = { * user : "御焱", * password : "123456" * } */ // 判断 query.user 和 query.password 格式是否正确 // 待办事项?? // 判断是否已经注册 // 待办事项?? // 判断姓名、学号是否正确 // 待办事项?? return ctx.body = { ok: true, msg: "登录成功", token: getToken({ user: query.user, password: query.password }) }}));前端获取到token之后，可以保存在任意本地存储里。4、信息/* GET /api/info 信息 */app.use(route.get("/api/info", async (ctx, next) => { // 前端访问时会附带token在请求头 payload = getJWTPayload(ctx.headers.authorization) /* * payload = { * user : "御焱", * iat : 1524042454, * exp : 1524056854 * } */ // 根据 payload.user 查询该用户在数据库中的信息 // 待办事项?? const info = { name: "御焱", age: 10, sex: "男" } let 获取信息成功 = true; if (获取信息成功) { return ctx.body = { ok: true, msg: "获取信息成功", data: info } } else { return ctx.body = { ok: false, msg: "获取信息失败" } }}));/* 通过token获取JWT的payload部分 */function getJWTPayload(token) { // 验证并解析JWT return jwt.verify(token.split(" ")[1], secret);}访问需要认证的接口时，需要在request头附带Authorization:Bearer [token]字段。相信看了本文案例你已经掌握了方法，更多精彩请关注Gxl网其它相关文章！推荐阅读：Vue.js开发mpvue框架步骤详解jquery fullpage插件添加头部与尾部版权相关vue里使用sass配置步骤详解

JWT是JSON WEB TOKEN的缩写，它是基于 RFC 7519 标准定义的一种可以安全传输的的JSON对象，由于使用了数字签名，所以是可信任和安全的。JWT的组成JWT token的格式：header.payload.signatureheader中用于存放签名的生成算法{"alg": "HS512"}Copy to clipboardErrorCopiedpayload中用于存放用户名、token的生成时间和过期时间{"sub":"admin","created":1489079981393,"exp":1489684781}Copy to clipboardErrorCopiedsignature为以header和payload生成的签名，一旦header和payload被篡改，验证将失败//secret为加密算法的密钥 String signature = HMACSHA512(base64UrlEncode(header) + "." +base64UrlEncode(payload),secret)

System.IdentityModel.Tokens.Jwt是.NET框架中用于生成和验证JSON Web Tokens（JWT）的类库。出现System.IdentityModel.Tokens.Jwt+类型初始值设定项引发异常的错误通常是由于使用过时或不兼容的System.IdentityModel.Tokens.Jwt版本或其依赖项。要解决此问题，您可以尝试以下解决方案：更新System.IdentityModel.Tokens.Jwt库到最新版本，并确保它与您的应用程序或项目中使用的其他库兼容。确认您的代码中没有使用不推荐使用或已弃用的API或方法。确认您的代码中的引用和依赖项是否正确，并且没有冲突或版本不兼容的问题。如果上述解决方案都不起作用，您可以尝试重新安装.NET框架或重建您的项目。如果您仍然无法解决此问题，请提供更多关于您的应用程序或项目的信息和代码示例，以便我可以更好地帮助您解决此问题。

根据欧拉公式，cos(3t)=/2。直流信号的傅里叶变换是专2πδ（ω）。根据频移性质可得exp(j3t)的傅里叶变换是2πδ（ω－3)。再根据线性性质，可得cos(3t)=/2的傅里叶变换是πδ（ω－3)+πδ（ω＋3)。三角函数一般用于计算三角形中未知长度的边和未知的角度，在导航、工程学以及物理学方面都有广泛的用途。另外，以三角函数为模版，可以定义一类相似的函数，叫做双曲函数。常见的双曲函数也被称为双曲正弦函数、双曲余弦函数等等。三角函数（也叫做圆函数）是角的函数；它们在研究三角形和建模周期现象和许多其他应用中是很重要的。三角函数通常定义为包含这个角的直角三角形的两个边的比率，也可以等价的定义为单位圆上的各种线段的长度。更现代的定义把它们表达为无穷级数或特定微分方程的解，允许它们扩展到任意正数和负数值，甚至是复数值。

@[TOC] @[TOC] 1.#Keycloak项目配置 步骤****1****：****Keycloak****入门 请参阅Keycloak入门 文档 以运行和设置keycloak管理员用户。 运行Keycloak后，使用 http：// localhost：8080 / auth 访问keycloak管理控制台 设置keycloak用户名= admin，密码= admin。 第****2****步：创建开发领域 名称：coablt [图片上传失败...(image-9626fc-1578649185668)] 图1：添加开发领域 客户端ID： account 客户端协议： openid-connect 启用直接访问授权Direct Access Grants Enabled ：No 服务帐号已启用 Service Accounts Enabled ：No 授权已启用 Authorization Enabled****：****No [图片上传失败...(image-904bdf-1578649185668)] 步骤****4****：创建客户端角色 在客户端下创建一个角色。在这种情况下，角色admin在雇员服务下创建。 [图片上传失败...(image-1be1e9-1578649185668)] 图3：创建角色 第****6****步：创建一个映射器（在访问令牌中获取****user_name****） Keycloak访问令牌是 JWT 。它是一个JSON，并且该JSON中的每个字段都称为声明。默认情况下，登录用户名会在访问令牌中名为“ preferred_username”的声明中返回。Spring Security OAuth2资源服务器在名为 “ user_name” 的声明中需要用户名。因此，我们必须创建下面的映射器，以将登录的用户Id映射到名为user_name的新声明。 [图片上传失败...(image-693526-1578649185668)] 图4：创建映射器 步骤****7****：建立使用者 [图片上传失败...(image-b16592-1578649185668)] 图5：创建用户 步骤****8****：将客户端角色映射到用户 为了提供对客户端（微服务）的访问，需要为用户分配/映射相应的角色。 [图片上传失败...(image-c5609f-1578649185668)] 图6：为用户分配角色 使用****PostMan****获取访问令牌（用于测试） 选择 授权 类型为OAuth 2.0，点击“获取新访问令牌”，然后输入以下详细信息。 [图片上传失败...(image-6f4c53-1578649185668)] 邮递员工具屏幕快照：从客户端的密钥斗篷获取访问令牌 · 确保在请求令牌时选择客户端身份验证作为“在正文中发送客户端凭据”。 · 回调URL是在Keycloak中配置的重定向URL。 · 客户端机密可能与您不同，请从客户端配置中的密钥库中复制一个。 · 您也可以使用 https://jwt.io 检查收到的令牌的内容。 步骤****10****：创建一个****Spring Boot****应用程序 [图片上传失败...(image-45efc0-1578649185668)] 依存关系 [图片上传失败...(image-d66a1b-1578649185668)] 步骤****11****：配置****application.yml 常规安全属性 [图片上传失败...(image-992887-1578649185668)] 使用****OAuth2****资源服务器保护****REST****端点的属性 [图片上传失败...(image-aa43c4-1578649185668)] 图7：复制jwt公钥值 注******1******：****可以从领域级别的公钥复制 security.oauth2.resource.jwt.key-value 属性值。这非常重要，此属性是使用****JwtAccessTokenCustomizer******的****属性，我们将在后面看到。 ** 注意******2******：****属性值会根据您的配置而有所不同，应注意使用正确的值。 步骤****12****：配置****APi****管理账户 [图片上传失败...(image-b408a1-1578649185667)] [图片上传失败...(image-71cf2b-1578649185667)] [图片上传失败...(image-70e51d-1578649185667)] [图片上传失败...(image-974948-1578649185667)] 步骤****13****：配置后台****APi****管理账户 因为项目初始化了Admin超级管理员，所以需要keycloak配置一个admin的新用户 然后将该用户ID 复制到sys_user表的Oauth2_id字段内 [图片上传失败...(image-715b3b-1578649185667)]

sin(wt)=[e^(jwt)-e^(-jwt)]／2；则单边拉普拉斯变换为：L[e^(jwt)]/2j-L[e^(-jwt)]/2j=[(s-jw)*j]/2-[(s+jw)*j]/2=w/(s^2+w^2)

Struts+Hibernate+Spring (清华大学出版社)可供你参考！

1/[jw（1+jwT）]=j(1-jwt)/[j*jw（1+jwT）(1-jwt)] =(j+wt)/[-w(1+w^2T^2)] =-t/(1+w^2T^2)-jw/(1+w^2T^2) 利用j^2=-1

你是概念没有搞清楚。在时谐电场中的瞬时表达式E(t）=Ecos(wt-kz).它可以用复数的实部来表示E(t）=Re[Ee^j(wt-kz)],e^j(wt-kz)取实部就是cos(wt-kz)，所以e^j(wt-kz)才是表示相位，请不要认为e^(iwt)表示相位。将e^j(wt-kz)拆开，得e^jwt和e^-jkz。同时得E(t）=Re[Ee^-jkze^jwt],E(t）=Re[EU（z)e^jwt]中U（z)=Ee^-jkz表示复矢量。在时谐场中所有时谐量都相同，为了方便起见将e^jwt省略，一般是用复矢量E(z）=Ee^-jkz表示，所以在题中一般给的就是复矢量E(z）=Ee^-jkz，学电磁学的一看到E(z）=Ee^-jkz就知道这是复矢量并能加上e^jwt取实部得到瞬时表达式E(t）=Ecos(wt-kz).所以你上面提的问题本身就是错误的。如果这样解释还是没搞明白的话，请参看《电磁场与电磁波》中的“时谐电磁场”。

常见的鉴权方式有两种，一种是基于session，另一种是基于token方式的鉴权，我们来浅谈一下两种 鉴权方式的区别。 session token 业界常用的授权标准有两种，一种是使用auth2，这种方式更适合于类似第三方授权登录，比如微信、微博、QQ信任登录业务。另一种是oauth，即第三方无需知道用户和密码就可以申请获得该资源的授权，更适用于对用户的权限校验并分配访问权限，比如常见的登录后分配可见资源（按钮、菜单等）类型网站。 Javashop电商系统 采用的是oauth方式的鉴权标准。我们以系统的应用为例来介绍oauth的方案。 1. 登录 服务端校验密码，成功后返回access_token和refresh_token，客户端记录上述token。 2. 访问API 在访问API之前解析access_token，并且查看是否过期，如果不过 期则请求API，如果过期，则要刷新令牌，在请求API。 3. 刷新token 携带有效期的refresh_token换回有效token，如果refresh_token过期，则需要用户重新登录。 4. 注销 请求注销api，服务器端和客户端应同时删除token的存储。 1. 客户端请求API 携带access_token信息，如果生成环境不会直接携带access_token，会使用加密后的签名校验。祥见以下防重放机制。 2. 获取token 根据环境不同而有不同的获取token方式。 3. 解析token 通过JWT工具将token解析。 4. 由redis读取token 根据uid拼接key读取access_token, 如果不存在这个用户的token说明已经登出。 5. 验证token 判断次token是否属于此uid，判断token是否过期，如果过期则进行以下刷新token的流程。 6. 注入权限 如果token验证成功，根据user信息生成权限注入到spring安全上下文中。 1. 客户端请求API 携带refresh_token，如果是生产环境不会直接携带refresh_token信息，详见以下防重放攻击。 2. 获取token 根据环境不同而有不同的获取token方式。 3. 解析token 通过JWT工具将token解析。 4. token读取 根据uid拼接key读取出access_token，如果不存在这个用户的token说明用户已经登出。 5. 验证token 判断此token是否属于此uid，判断token是否已经过期，如果过期，则返回refresh_token过期错误，此时用户需要重新登录。 6. 刷新token 如果refresh_token 验证成功，则重新生成access_token和refresh_token，上述有效期以当前时间向后计算，替换此用户在redis中的token，并将token返回给客户端。 一、 参数的读取 1. 在生产环境时，不能直接传递token,而是要传递签名数据，服务器端验签后由Redis中获取签名。 2. 如果是非生产环境，直接由header中读取token。 二、 生产环境传递如下参数 memberid (用户id) nonce（随机字串，6位） timestamp(当前时间戳，到秒) sign= md5( uid+ nonce + timestamp +token ) 三、 验证逻辑 1. 验证时间戳 判断时间戳是否起过60s，大于60s则判别为重放功击。 2. 验证nonce 首先验证nonce在 reids中是否存在，如果存在，则判别为重放功击，否则将nonce记录在redis中（key为："nonce"+uid+"_"+nonce），失效时间为60s。 3. 验证sign md5( uid+ nonce + timestamp +token ) 验证是签名是否通过。 4. 验证token 通过uid拿到token ，验证逻辑同验权流程。 当然在不同的业务场景下实现方案是多种多样的，仅以此方案抛转引玉，供大家参考。

sin(wt)=[e^(jwt)-e^(-jwt)]／2；则单边拉普拉斯变换为：L[e^(jwt)]/2j-L[e^(-jwt)]/2j=[(s-jw)*j]/2-[(s+jw)*j]/2=w/(s^2+w^2)

解：1/[jw（1+jwT）]=j(1-jwt)/[j*jw（1+jwT）(1-jwt)]=(j+wt)/[-w(1+w^2T^2)]=-t/(1+w^2T^2)-jw/(1+w^2T^2)利用j^2=-1

该类实现了UserDetails接口 内含登录成功或失败后的处理方法 用一个简单的类来接受前端出来的登录信息 实现UserDetailsService接口，重写loadUserByUsername方法，按自己的实际需求来编写验证规则 该类为token校验器，并封装了用户权限，保存至security上下文中 首先SysUserController中有三个测试接口，第一个接口认证后即可访问，第二个接口需要登录的用户拥有ROLE_ADMIN角色，第三个接口需要用户拥有ROLE_USER角色。 返回了token信息 请求头中带上token，因为security配置类中关闭了session，后续请求必须带上token才能访问。 访问成功。 该接口需要ROLE_ADMIN，我们已登录的用户只拥有ROLE_USER，所以该接口不能访问。 结果符合预期 该接口需要ROLE_USER，已登录用户可以访问 结果符合预期 项目源码地址： https://github.com/lan-de/SpringSecurity-01

w为正值时，向量逆时针旋转；w为负值时，向量顺时针旋转e^jwt在复平面上表示绕原点旋转的圆，w为角速度，wt表示变化角度，复平面图像由角度和模构成，少了t没有角度自然不能构成图像了。同样，e^jwt在时域上还可表示成正弦图像，少了一个t轴，自然也不能构成二维图像了。数学中，复平面（complexplane）是用水平的实轴与垂直的虚轴建立起来的复数的几何表示。它可视为一个具有特定代数结构笛卡儿平面（实平面），一个复数的实部用沿着x-轴的位移表示，虚部用沿着y-轴的位移表示。复平面有时也叫做阿尔冈平面，因为它用于阿尔冈图中。这是以让-罗贝尔·阿尔冈（1768-1822）命名的，尽管它们最先是挪威-丹麦土地测量员和数学家卡斯帕尔·韦塞尔（1745-1818）叙述的。阿尔冈图经常用来标示复平面上函数的极点与零点的位置。

最近在重构公司以前产品的前端代码，摈弃了以前的session-cookie鉴权方式，采用token鉴权，忙里偷闲觉得有必要对几种常见的鉴权方式整理一下。目前我们常用的鉴权有四种： HTTP Basic Authentication session-cookie Token 验证 OAuth(开放授权)一.HTTP Basic Authentication 这种授权方式是浏览器遵守http协议实现的基本授权方式,HTTP协议进行通信的过程中，HTTP协议定义了基本认证认证允许HTTP服务器对客户端进行用户身份证的方法。认证过程：1． 客户端向服务器请求数据，请求的内容可能是一个网页或者是一个ajax异步请求，此时，假设客户端尚未被验证，则客户端提供如下请求至服务器:Get /index.html HTTP/1.0 Host:www.google.com2． 服务器向客户端发送验证请求代码401,（WWW-Authenticate: Basic realm=”google.com”这句话是关键，如果没有客户端不会弹出用户名和密码输入界面）服务器返回的数据大抵如下：HTTP/1.0 401 Unauthorised Server: SokEvo/1.0 WWW-Authenticate: Basic realm=”google.com” Content-Type: text/html Content-Length: xxx3． 当符合http1.0或1.1规范的客户端（如IE，FIREFOX）收到401返回值时，将自动弹出一个登录窗口，要求用户输入用户名和密码。4． 用户输入用户名和密码后，将用户名及密码以BASE64加密方式加密，并将密文放入前一条请求信息中，则客户端发送的第一条请求信息则变成如下内容：Get /index.html HTTP/1.0 Host:www.google.com Authorization: Basic d2FuZzp3YW5n注：d2FuZzp3YW5n表示加密后的用户名及密码（用户名：密码 然后通过base64加密，加密过程是浏览器默认的行为，不需要我们人为加密，我们只需要输入用户名密码即可）5． 服务器收到上述请求信息后，将Authorization字段后的用户信息取出、解密，将解密后的用户名及密码与用户数据库进行比较验证，如用户名及密码正确，服务器则根据请求，将所请求资源发送给客户端效果：客户端未未认证的时候，会弹出用户名密码输入框，这个时候请求时属于pending状态，这个时候其实服务当用户输入用户名密码的时候客户端会再次发送带Authentication头的请求。认证成功：server.jslet express = require("express");let app = express(); app.use(express.static(__dirname+"/public")); app.get("/Authentication_base",function(req,res){ console.log("req.headers.authorization:",req.headers) if(!req.headers.authorization){ res.set({ "WWW-Authenticate":"Basic realm="wang"" }); res.status(401).end(); }else{ let base64 = req.headers.authorization.split(" ")[1]; let userPass = new Buffer(base64, "base64").toString().split(":"); let user = userPass[0]; let pass = userPass[1]; if(user=="wang"&&pass="wang"){ res.end("OK"); }else{ res.status(401).end(); } } }) app.listen(9090)index.html:<!DOCTYPE html><html> <head> <meta charset="UTF-8"> <title>HTTP Basic Authentication</title> </head> <body> <div></div> <script src="js/jquery-3.2.1.js"></script> <script> $(function(){ send("./Authentication_base"); }) var send = function(url){ $.ajax({ url : url, method : "GET", }); } </script> </body></html>当然有登陆就有注销，我们会发现当我们认证成功后每次请求请求头都会带上Authentication及里面的内容，那么如何做到让这次登陆失效的？网上查了半天，目前最有效的方式就是在注销操作的时候，专门在服务器设置一个专门的注销账号，当接收到的Authentication信息为注销用户名密码的时候纠就带便注销成功了，而客户端在注销操作的时候，手动的的去修改请求头重的Authentication，将他设置未服务器默认的注销账号和密码。通过上面的简单讲解 其实我们已经可以返现这种验证方式的缺陷加密方式简单，仅仅是base64加密，这种加密方式是可逆的。同时在每个请求的头上都会附带上用户名和密码信息，这样在外网是很容易被嗅探器探测到的。总结:正式因为这样，这种加密方式一般多被用在内部安全性要求不高的的系统上，只是相对的多，总的来说现在使用这种鉴权比较少了。如果项目需要部署在公网上，这种方式不推荐，当然你也可以和SSL来加密传输，这样会好一点，这个如果我后面有时间来研究一下。二.session-cookie第二种这个方式是利用服务器端的session（会话）和浏览器端的cookie来实现前后端的认证，由于http请求时是无状态的，服务器正常情况下是不知道当前请求之前有没有来过，这个时候我们如果要记录状态，就需要在服务器端创建一个会话(seesion),将同一个客户端的请求都维护在各自得会会话中，每当请求到达服务器端的时候，先去查一下该客户端有没有在服务器端创建seesion，如果有则已经认证成功了，否则就没有认证。 session-cookie认证主要分四步： 1，服务器在接受客户端首次访问时在服务器端创建seesion，然后保存seesion(我们可以将seesion保存在内存中，也可以保存在redis中，推荐使用后者)，然后给这个session生成一个唯一的标识字符串,然后在响应头中种下这个唯一标识字符串。 2.签名。这一步只是对sid进行加密处理，服务端会根据这个secret密钥进行解密。（非必需步骤） 3.浏览器中收到请求响应的时候会解析响应头，然后将sid保存在本地cookie中，浏览器在下次http请求de 请求头中会带上该域名下的cookie信息， 4.服务器在接受客户端请求时会去解析请求头cookie中的sid，然后根据这个sid去找服务器端保存的该客户端的session，然后判断该请求是否合法。server.js(nodejs+express+seesion+redis)var express = require("express");var RedisStore = require("connect-redis")(express.session);var app = express();var secret = "wang839305939"// 设置 Cookieapp.use(express.cookieParser(secret));// 设置 Sessionapp.use(express.session({ store: new RedisStore({ host: "127.0.0.1", port: 6379, db: "session_db" }), secret: secret}))app.get("/", function(req, res) { var session = req.session; session.time= session.time|| 0; var n = session.time++; res.send("hello, session id:" + session.id + " count:" + n);});app.listen(9080);三.Token 验证使用基于 Token 的身份验证方法，大概的流程是这样的：1. 客户端使用用户名跟密码请求登录 2. 服务端收到请求，去验证用户名与密码 3. 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端 4. 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里 5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token 6. 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据总的来说就是客户端在首次登陆以后，服务端再次接收http请求的时候，就只认token了，请求只要每次把token带上就行了，服务器端会拦截所有的请求，然后校验token的合法性，合法就放行，不合法就返回401（鉴权失败）。乍的一看好像和前面的seesion-cookie有点像，seesion-cookie是通过seesionid来作为浏览器和服务端的链接桥梁，而token验证方式貌似是token来起到seesionid的角色。其实这两者差别是很大的。 1. sessionid 他只是一个唯一标识的字符串，服务端是根据这个字符串，来查询在服务器端保持的seesion，这里面才保存着用户的登陆状态。但是token本身就是一种登陆成功凭证，他是在登陆成功后根据某种规则生成的一种信息凭证，他里面本身就保存着用户的登陆状态。服务器端只需要根据定义的规则校验这个token是否合法就行。 2. session-cookie是需要cookie配合的，居然要cookie，那么在http代理客户端的选择上就是只有浏览器了，因为只有浏览器才会去解析请求响应头里面的cookie,然后每次请求再默认带上该域名下的cookie。但是我们知道http代理客户端不只有浏览器，还有原生APP等等，这个时候cookie是不起作用的，或者浏览器端是可以禁止cookie的(虽然可以，但是这基本上是属于吃饱没事干的人干的事)?，但是token 就不一样，他是登陆请求在登陆成功后再请求响应体中返回的信息，客户端在收到响应的时候，可以把他存在本地的cookie,storage，或者内存中，然后再下一次请求的请求头重带上这个token就行了。简单点来说cookie-session机制他限制了客户端的类型，而token验证机制丰富了客户端类型。 3. 时效性。session-cookie的sessionid实在登陆的时候生成的而且在登出事时一直不变的，在一定程度上安全就会低，而token是可以在一段时间内动态改变的。 4. 可扩展性。token验证本身是比较灵活的，一是token的解决方案有许多，常用的是JWT,二来我们可以基于token验证机制，专门做一个鉴权服务，用它向多个服务的请求进行统一鉴权。下面就拿最常用的JWT（JSON WEB TOKEN）来说： JWT是Auth0提出的通过对JSON进行加密签名来实现授权验证的方案，就是登陆成功后将相关信息组成json对象，然后对这个对象进行某中方式的加密，返回给客户端，客户端在下次请求时带上这个token，服务端再收到请求时校验token合法性，其实也就是在校验请求的合法性。 JWT对象通常由三部分构成：Headers： 包括类别（typ）、加密算法（alg） { "alg": "HS256", "typ": "JWT" }Claims ：包括需要传递的用户信息 { "sub": "1234567890", "name": "John Doe", "admin": true }Signature： 根据alg算法与私有秘钥进行加密得到的签名字串， 这一段是最重要的敏感信息，只能在服务端解密；HMACSHA256( base64UrlEncode(Headers) + "." + base64UrlEncode(Claims), SECREATE_KEY)编码之后的JWT看起来是这样的一串字符：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQnodejs+express+jwt-simple auth.jslet jwt = require("jwt-simple");let secret = "wangyy";let time = 10; module.exports = { /* *检验token合法性 */ validate:function(req,res,next){ let token = req.body.token||req.headers["xssToken"]; if(token){ let decodeToken = null; try { //防止假冒token解析__ decodeToken = jwt.decode(token,secret,"HS256"); } catch (err) { res.status(401).send("非法访问"); return; } let exp = decodeToken.exp; if(!exp){ res.status(401).send("非法访问"); } let now = new Date().getTime(); if(exp>(now+time*60*1000)){ res.send({code:"002","errorMsg":"授权超时"}) } next(); }else{ res.status(401).send("非法访问"); } }, /* 生成token*/ makeToken(){ let Token = null; let payload = { time:new Date().getTime(), exp:this.makeExp(time) } Token = jwt.encode(payload,secret,HS256) return Token; }, /*生成token过期时间*/ makeExp:function(time){ let stam = time601000; } }server.jslet express = require("express"); let app = express(); let bodyParser = require("body-parser"); let auth = require("./lib/auth.js"); let chalk = require("chalk"); app.use(bodyParser.json()); app.post("/login",function(req,res,next){ let Token = auth.makeToken(); res.json({result:"success",token:Token},200) });app.use("*",[auth.validate],function(req,res,next){ res.send("success"); }); app.listen("9999")上面只是一个简单的token生成和校验，如果有需要可以根据实际需要进行逻辑处理四.OAuth(开放授权)OAuth（开放授权）是一个开放标准，允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方网站或分享他们数据的所有内容，为了保护用户数据的安全和隐私，第三方网站访问用户数据前都需要显式的向用户征求授权。我们常见的提供OAuth认证服务的厂商有支付宝，QQ,微信。 OAuth协议又有1.0和2.0两个版本。相比较1.0版，2.0版整个授权验证流程更简单更安全，也是目前最主要的用户身份验证和授权方式。 下面是一张auth2.0的流程图： 从图中我们可以看出，auth2.0流程分为六布（我们就以csdn登陆为例）：第一步. 向用户请求授权，现在很多的网站在登陆的时候都有第三方登陆的入口，当我们点击等第三方入口时，第三方授权服务会引导我们进入第三方登陆授权页面。通过第三方请求授权页面的浏览器地址栏地址可以看出，https://graph.qq.com/oauth2.0/show?which=Login&display=pc&response_type=code&client_id=100270989&redirect_uri=https%3A%2F%2Fpassport.csdn.net%2Faccount%2Flogin%3Foauth_provider%3DQQProvider&state=test这里的地址里面的%是浏览器强制编码后的显示我们可以使用decodeURIComponent进行解码，解码后是这样：https://graph.qq.com/oauth2.0/show?which=Login&display=pc&response_type=code&client_id=100270989&redirect_uri=https://passport.csdn.net/account/login?oauth_provider=QQProvider&state=test这个url地址我们可以看见Auth2.0常见的几个参数： response_type，返回类型 client_id，第三方应用id,由授权服务器（qq）在第三方应用提交时颁发给第三方应用。 redirect_uri，登陆成功重定向页面 oauth_provider，第三方授权提供方 state，由第三方应用给出的随机码 第二步. 返回用户凭证（code），并返回一个凭证（code），当用户点击授权并登陆后，授权服务器将生成一个用户凭证（code）。这个用户凭证会附加在重定向的地址redirect_uri的后面https://passport.csdn.net/account/login?code=9e3efa6cea739f9aaab2&state=XXX第3步. 请求授权服务器授权:经过第二部获取code后后面的工作就可以交给后台去处理的，和用户的交互就结束了。接下来我的需要获取Access Token，我们需要用他来向授权服务器获取用户信息等资源。 第三方应用后台通过第二步的凭证（code）向授权服务器请求Access Token，这时候需要以下几个信息： client_id 标识第三方应用的id，由授权服务器（Github）在第三方应用提交时颁发给第三方应用 client_secret 第三方应用和授权服务器之间的安全凭证，由授权服务器（Github）在第三方应用提交时颁发给第三方应用 code 第一步中返回的用户凭证redirect_uri 第一步生成用户凭证后跳转到第二步时的地址 state 由第三方应用给出的随机码第四步. 授权服务器同意授权后，返回一个资源访问的凭证（Access Token）。第五步. 第三方应用通过第四步的凭证（Access Token）向资源服务器请求相关资源。第六步. 资源服务器验证凭证（Access Token）通过

react实现路由可以直接使用react-router。ReactRouter是由Ryan Florence开发的应用于ReactJS的路由组件，它通过定义ReactJS组件<Routes>及相关子组件来实现页面路由的映射、参数的解析和传递。以下是例子：var ReactRouter = require("react-router"); var Routes = ReactRouter.Routes; var Route = ReactRouter.Route;//定义整个页面的路由结构var routes = ( <Routes location="hash"><Route path="/" handler={App}><Route path="books" name="bookList" handler={Books}/><Route path="movies" name="movieList" handler={Movies}/></Route></Routes>);