十、SpringSecurity微服务权限方案（1）

微服务最早由Martin Fowler 与 James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。

微服务每个模块就相当于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。微服务每个模块都可以使用不同的存储方式（比如有的用redis、有的用MySQL等），数据库也是单个模块对应自己的数据库。微服务每个模块都可以使用不同的开发技术，开发模式更灵活。

微服务，关键其实不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构使得微服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务于微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等。微服务的目的是有效的拆分应用，实现敏捷开发和部署。

如果是基于session，那么Spring Security会对cookie里的sessionid进行解析，找到服务器存储的session信息，然后判断当前用户是否符合请求的要求。如果是基于token，则是解析出token，然后将当前请求加入到Spring Security管理的权限信息中去。
如果系统的模块众多，每个模块都需要进行授权与认证，所以我们选择基于 token 的形式进行授权与认证，用户根据用户名密码认证成功，然后获取当前用户角色的一系列权限值，并以用户名为 key，权限列表为 value 的形式存入 redis 缓存中，根据用户名相关信息生成 token 返回，浏览器将 token 记录到 cookie 中，每次调用 api 接口都默认将 token 携带到 header 请求头中，Spring Security 解析 header 头获取 token 信息，解析 token 获取当前用户名，根据用户名就可以从 redis 中获取权限列表，这样 Spring Security 就能够判断当前请求是否有权限访问。

典型的，一个jwt看起来如下图：

该对象为一个很长的字符串，字符之间通过"."分隔符分为三个子串。
每一个子串表示了一个功能快，总共有以下三个部分：jwt头、有效载荷和签名

JWT 头部分是一个描述 JWT 元数据的 JSON 对象，通常如下所示。

{
  "alg": "HS256",
  "typ": "JWT"
}

在上面的代码中，alg 属性表示签名使用的算法，默认为 HMAC SHA256（写为 HS256）；typ 属性表示令牌的类型，JWT 令牌统一写为 JWT。最后，使用 base64 URL 算法将上述JSON 对象转换为字符串保存。

有效载荷部分，是 JWT 的主体内容部分，也是一个 JSON 对象，包含需要传递的数据。 JWT指定七个默认字段供选择。

iss：发行人exp：到期时间sub：主题aud：用户nbf：在此之前不可用iat：发布时间jti：JWT ID 用于标识该 JWT
除以上默认字段外，我们还可以自定义私有字段，如下例：

{
  "sub": "1234567890",
  "name": "Helen",
  "admin": true
}

请注意，默认情况下 JWT 是未加密的，任何人都可以解读其内容，因此不要构建隐私信息字段，存放保密信息，以防止信息泄露。JSON 对象也使用 base64 URL 算法转换为字符串保存。

签名哈希部分是对上面两部分数据签名，通过指定的算法生成哈希，以确保数据不会被篡改。
首先，需要指定一个密码（secret）。该密码仅仅为保存在服务器中，并且不能向用户公开。然后，使用标头中指定的签名算法（默认情况下为 HMAC SHA256）根据以下公式生成签名。
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(claims), secret)
在计算出签名哈希后，JWT 头，有效载荷和签名哈希的三个部分组合成一个字符串，每个部分用".“分隔，就构成整个 JWT 对象。
base64URL 算法
如前所述，JWT 头和有效载荷序列化的算法都用到了 base64URL。该算法和常见 base64 算法类似，稍有差别。
作为令牌的 JWT 可以放在 URL 中（例如 api.example/?token=xxx）。 base64 中用的三个字符是”+"，"/“和”="，由于在 URL 中有特殊含义，因此 base64URL 中对他们做了替换："=“去掉，”+“用”-“替换，”/“用”_"替换，这就是 base64URL 算法。