分布式系统认证方案

随笔笔记1

1.1 什么是分布式系统

随着软件环境和需求的变化 ，软件的架构由单体结构演变为分布式架构，具有分布式架构的系统叫分布式系统，分 布式系统的运行通常依赖网络，它将单体结构的系统分为若干服务，服务之间通过网络交互来完成用户的业务处 理，当前流行的微服务架构就是分布式系统架构，如下图:

fbs.png

分布式系统具体如下基本特点: 1、分布性:每个部分都可以独立部署，服务之间交互通过网络进行通信，比如:订单服务、商品服务。 2、伸缩性:每个部分都可以集群方式部署，并可针对部分结点进行硬件及软件扩容，具有一定的伸缩能力。 3、共享性:每个部分都可以作为共享资源对外提供服务，多个部分可能有操作共享资源的情况。 4、开放性:每个部分根据需求都可以对外发布共享资源的访问接口，并可允许第三方系统访问。

1.2 分布式认证需求
分布式系统的每个服务都会有认证、授权的需求，如果每个服务都实现一套认证授权逻辑会非常冗余，考虑分布式 系统共享性的特点，需要由独立的认证服务处理系统认证授权的请求;考虑分布式系统开放性的特点，不仅对系统 内部服务提供认证，对第三方系统也要提供认证。分布式认证的需求总结如下:
统一认证授权 提供独立的认证服务，统一处理认证授权。
无论是不同类型的用户，还是不同种类的客户端(web端，H5、APP)，均采用一致的认证、权限、会话机制，实现 统一认证授权。

要实现统一则认证方式必须可扩展，支持各种认证需求，比如:用户名密码认证、短信验证码、二维码、人脸识别等认证方式，并可以非常灵活的切换。 应用接入认证应提供扩展和开放能力，提供安全的系统对接机制，并可开放部分API给接入第三方使用，一方应用(内部 系统服 务)和三方应用(第三方应用)均采用统一机制接入。

1.3 分布式认证方案
1.3.1 选型分析
1、基于session的认证方式 在分布式的环境下，基于session的认证会出现一个问题，每个应用服务都需要在session中存储用户身份信息，通过负载均衡将本地的请求分配到另一个应用服务需要将session信息带过去，否则会重新认证。

session.png

这个时候，通常的做法有下面几种: Session复制:多台应用服务器之间同步session，使session保持一致，对外透明。 Session黏贴:当用户访问集群中某台服务器后，强制指定后续所有请求均落到此机器上。 Session集中存储:将Session存入分布式缓存中，所有服务器应用实例统一从分布式缓存中存取Session。
总体来讲，基于session认证的认证方式，可以更好的在服务端对会话进行控制，且安全性较高。但是，session机 制方式基于cookie，在复杂多样的移动客户端上不能有效的使用，并且无法跨域，另外随着系统的扩展需提高 session的复制、黏贴及存储的容错性。

2、基于token的认证方式
基于token的认证方式，服务端不用存储认证数据，易维护扩展性强， 客户端可以把token 存在任意地方，并且可 以实现web和app统一认证机制。其缺点也很明显，token由于自包含信息，因此一般数据量较大，而且每次请求 都需要传递，因此比较占带宽。另外，token的签名验签操作也会给cpu带来额外的处理负担。

1.3.2 技术方案
根据 选型的分析，决定采用基于token的认证方式，它的优点是:
1、适合统一认证的机制，客户端、一方应用、三方应用都遵循一致的认证机制。 2、token认证方式对第三方应用接入更适合，因为它更开放，可使用当前有流行的开放协议Oauth2.0、JWT等。 3、一般情况服务端无需存储会话信息，减轻了服务端的压力。
分布式系统认证技术方案见下图:

fa.png

流程描述:
(1)用户通过接入方(应用)登录，接入方采取OAuth2.0方式在统一认证服务(UAA)中认证。
(2)认证服务(UAA)调用验证该用户的身份是否合法，并获取用户权限信息。
(3)认证服务(UAA)获取接入方权限信息，并验证接入方是否合法。
(4)若登录用户以及接入方都合法，认证服务生成jwt令牌返回给接入方，其中jwt中包含了用户权限及接入方权 限。
(5)后续，接入方携带jwt令牌对API网关内的微服务资源进行访问。 (6)API网关对令牌解析、并验证接入方的权限是否能够访问本次请求的微服务。
(7)如果接入方的权限没问题，API网关将原请求header中附加解析后的明文Token，并将请求转发至微服务。
(8)微服务收到请求，明文token中包含登录用户的身份和权限信息。因此后续微服务自己可以干两件事:
1，用 户授权拦截(看当前用户是否有权访问该资源)
2，将用户信息存储进当前线程上下文(有利于后续业务逻辑随时 获取当前用户信息)
流程所涉及到UAA服务、API网关这三个组件职责如下:
1)统一认证服务(UAA) 它承载了OAuth2.0接入方认证、登入用户的认证、授权以及生成令牌的职责，完成实际的用户认证、授权功能。
2)API网关
作为系统的唯一入口，API网关为接入方提供定制的API集合，它可能还具有其它职责，如身份验证、监控、负载均 衡、缓存等。API网关方式的核心要点是，所有的接入方和消费端都通过统一的网关接入微服务，在网关层处理所 有的非业务功能。

补充：

1. 什么是会话：
   用户认证通过后，为了避免用户的每次操作都进行认证可将用户的信息保证在会话中。会话就是系统为了保持当前
   用户的登录状态所提供的机制，常见的有基于session方式、基于token方式等。
   基于session方式的交互流程是，用户认证成功后，在服务端生成用户相关的数据保存在session(当前会话)中，发给客户端的 sesssion_id 存放到 cookie 中，这样用户客户端请求时带上 session_id 就可以验证服务器端是否存在 session 数 据，以此完成用户的合法校验，当用户退出系统或session过期销毁时,客户端的session_id也就无效了。
   基于token方式的交互流程是，用户认证成功后，服务端生成一个token发给客户端，客户端可以放到 cookie 或 localStorage等存储中，每次请求时带上 token，服务端收到token通过验证后即可确认用户身份。
   基于session的认证方式由Servlet规范定制，服务端要存储session信息需要占用内存资源，客户端需要支持 cookie; 基于token的方式则一般不需要服务端存储token，并且不限制客户端的存储方式。如今移动互联网时代 更多类型的客户端需要接入系统，系统多是采用前后端分离的架构进行实现，所以基于token的方式更适合。

2. 什么是授权
   拿微信来举例子，微信登录成功后用户即可使用微信的功能，比如，发红包、发朋友圈、添加好友等，没有绑定 银行卡的用户是无法发送红包的，绑定银行卡的用户才可以发红包，发红包功能、发朋友圈功能都是微信的资源即 功能资源，用户拥有发红包功能的权限才可以正常使用发送红包功能，拥有发朋友圈功能的权限才可以使用发朋友 圈功能，这个根据用户的权限来控制用户使用资源的过程就是授权。
   为什么要授权?
   认证是为了保证用户身份的合法性，授权则是为了更细粒度的对隐私数据进行划分，授权是在认证通过后发生的， 控制不同的用户能够访问不同的资源。
   授权: 授权是用户认证通过根据用户的权限来控制用户访问资源的过程，拥有资源的访问权限则正常访问，没有权限则拒绝访问。

3. 授权的数据模型
   主体、资源、权限相关的数据模型如下:
   主体(用户id、账号、密码、...)
   资源(资源id、资源名称、访问地址、...)
   权限(权限id、权限标识、权限名称、资源id、...)
   角色(角色id、角色名称、...)
   角色和权限关系(角色id、权限id、...)
   主体(用户)和角色关系(用户id、角色id、...)
   通常企业开发中将资源和权限表合并为一张权限表，如下
   资源(资源id、资源名称、访问地址、...)
   权限(权限id、权限标识、权限名称、资源id、...)
   合并为: 权限(权限id、权限标识、权限名称、资源名称、资源访问地址、...)

一些资料笔记，记录一下。
公司saas平台基于session的认证方式，客户端以session_id与服务端保持会话。