SpringSecurity-基于微服务的认证与权限访问

目录

一、微服务概述

1.1 微服务由来

1.2 微服务优势

1.3 微服务本质

1.4 微服务的认证与授权实现思路

1.5 权限管理数据模型（举例）

二、JWT概述

2.1 Sesssion认证与Token认证的区别

2.2 JWT的结构

三、微服务权限认证模块（以后补充）

---

一、微服务概述

1.1 微服务由来

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

1.2 微服务优势

        （1）微服务每个模块就相当于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。

        （2）微服务每个模块都可以使用不同的存储方式（比如有的用 redis，有的用 mysql 等），数据库也是单个模块对应自己的数据库。

        （3）微服务每个模块都可以使用不同的开发技术，开发模式更灵活。

1.3 微服务本质

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

        （2）微服务的目的是有效的拆分应用，实现敏捷开发和部署。

1.4 微服务的认证与授权实现思路

        （1）如果是基于 Session，那么 Spring-security 会对 cookie 里的 sessionid 进行解析，找 到服务器存储的 session 信息，然后判断当前用户是否符合请求的要求。

        （2）如果是 token，则是解析出 token，然后将当前请求加入到 Spring-security 管理的权限 信息中去

        如果系统的模块众多，每个模块都需要进行授权与认证，所以我们选择基于 token 的形式 进行授权与认证。

        用户根据用户名、密码认证成功，然后获取当前用户角色的一系列权限值，并以用户名为 key，权限列表为 value 的形式存入 redis 缓存中，根据用户名相关信息生成 token 返回，浏览器将 token 记录到 cookie 中，每次调用 api 接口都默认将 token 携带到 header 请求头中，Spring-security 解析 header 头获取 token 信息，解析 token 获取当前用户名，根据用户名就可以从 redis 中获取权限列表，这样 Spring-security 就能够判断当前请求是否有权限访问。

1.5 权限管理数据模型（举例）

 

二、JWT概述

        Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

2.1 Sesssion认证与Token认证的区别

        1.Session

        http协议本身是一种无状态的协议，而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证，那么下一次请求时，用户还要再一次进行用户认证才行，因为根据http协议，我们并不能知道是哪个用户发出的请求，所以为了让我们的应用能识别是哪个用户发出的请求，我们只能在服务器存储一份用户登录的信息，这份登录信息会在响应时传递给浏览器，告诉其保存为cookie,以便下次请求时发送给我们的应用（sessionID），这样我们的应用就能识别请求来自哪个用户了,这就是传统的基于session认证。

        但是这种基于session的认证使应用本身很难得到扩展，随着不同客户端用户的增加，独立的服务器已无法承载更多的用户，而这时候基于session认证应用的问题就会暴露出来.

        2.Token

        基于token的鉴权机制类似于http协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利。

        流程上是这样的：

• 用户使用用户名密码来请求服务器
• 服务器进行验证用户的信息
• 服务器通过验证发送给用户一个token
• 客户端存储token，并在每次请求时附送上这个token值
• 服务端验证token值，并返回数据

        这个token必须要在每次请求时传递给服务端，它应该保存在请求头里

2.2 JWT的结构

        总共有以下三个部分：JWT 头、有效载荷和签名

 

       1. JWT 头部分是一个描述 JWT 元数据的 JSON 对象

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

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

                 iss：发行人

                exp：到期时间

                sub：主题

                aud：用户

                nbf：在此之前不可用

                iat：发布时间

                jti：JWT ID 用于标识该 JWT

                除以上默认字段外，我们还可以自定义私有字段

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

        注：默认情况下 JWT 是未加密的，任何人都可以解读其内容，因此不要构建隐私信息字段，存放保密信息，以防止信息泄露。

        3.签名哈希是对上面两部分数据签名，通过指定的算法生成哈希，以确保数据不会被篡改。

        在计算出签名哈希后，JWT 头，有效载荷和签名哈希的三个部分组合成一个字符串，每个部分用" . "分隔，就构成整个 JWT 对象。

三、微服务权限认证模块（以后补充）