① 鉴权必须了解的 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 Introction - 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..com tieba..com，就好办了。可以直接把 cookie domain 设置为主域名 .com，网络也就是这么干的。
比如滴滴这么潮的公司，同时拥有didichuxing.com xiaojukeji.com didiglobal.com等域名，种 cookie 是完全绕不开的。这要能实现「一次登录，全线通用」，才是真正的单点登录。这种场景下，我们需要独立的认证服务，通常被称为 SSO。 「一次「从 A 系统引发登录，到 B 系统不用登录」的完整流程」
**「完整版本：考虑浏览器的场景」**上面的过程看起来没问题，实际上很多 APP 等端上这样就够了。但在浏览器下不见得好用。看这里：
对浏览器来说，SSO 域下返回的数据要怎么存，才能在访问 A 的时候带上？浏览器对跨域有严格限制，cookie、localStorage 等方式都是有域限制的。这就需要也只能由 A 提供 A 域下存储凭证的能力。一般我们是这么做的：
图中我们通过颜色把浏览器当前所处的域名标记出来。注意图中灰底文字说明部分的变化。
谢谢大家哦
② 单点登录JWT与Spring Security OAuth
通过 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，则提示用户 重新登录 。