需求分析
随着软件环境和需求的变化，软件的架构由单体结构演变成具有分布式架构的分布式系统。而分布式系统的每个服务都会有认证、授权的需求。如果每个服务都实现一套认证逻辑，就会非常冗余。而针对分布式系统的特点，一般就会需要一套独立的第三方系统来提供统一的授权认证服务。分布式系统认证的需求总结如下：
统一认证授权
提供独立的认证服务，统一处理认证授权。无论是不同类型的用户、还是不同类型的客户端(Web、H5、App等)，均采用一致的认证、授权、会话判断机制，实现统一认证授权服务。
要实现这种统一的认证方式必须可扩展，支持各种认证需求。例如用户名密码、 短信验证码、二维码、人脸识别等各种认证方式，并可以灵活的切换。
多样的认证场景
例如购物、支付需要有不同的安全级别，也就需要有对应的认证场景。
应用接入认证
提供扩展和开放的能力，提供安全的系统对接机制，开放部分API给第三方使用。并且内部服务和外部第三方服务均采用统一的接入机制。
分布式认证方案
分布式环境下的认证方案主要有基于Session和基于Token两种方案。
基于Session的认证方式
这种方式依然由服务端保存统一的用户信息。只是在分布式环境下，将Session信息同步到各个服务中，并对请求进行均衡的负载。
- Session复制。在多台应用服务器之间同步session，并使session保持一致，对外透明。
- Session黏贴。当用户访问集群中某台服务器后，强制指定后续所有强求均落到此机器上。
- Session集中存储。将Session存入分布式缓存中，所有服务器应用实例都统一从分布式缓存中获取Session信息。
总体来讲，基于Session认证的方式，可以更好的在服务端对会话进行控制，且安全性较高。但是session机制总体是基于cookie的，客户端需要保存sessionId，在复杂多样的客户端上不能有效的使用。另外随着系统的扩展需要提高session的复制、黏贴及存储的容错性。
基于Token的认证方式
服务端不再存储认证数据，易维护，扩展性强。客户端可以把Token存在任意地方，并且可以实现web和app统一认证机制。其缺点也很明显，客户端信息容易泄露，token由于包含了大量信息，因此一般数据量较大，而且每次请求都需要传递，因此比较占带宽。另外，token的签名延签操作也会给系统带来额外的负担。
方案选型
通常情况下，还是会选择更通用的基于token的方式，这样能保证整个系统更灵 活的扩展性，并减轻服务端的压力。在这种方案下，一般会独立出 统一认证服务(UAA) 和网关两个部分来一起完成认证授权服务。
统一认证服务承载接入方认证、登入用户认证、授权以及令牌管理的职责，完成实际的用户认证、授权功能。
API网关会作为整个分布式系统的唯一入口，API网关为接入方提供API结合。 它本身还可能具有其他辅助职责，如身份验证、监控、负载均衡、缓存、协议转换等功能。API网关方式的核心要点是，所有的接入方和消费端都通过统一的网关接入微服务，在网关层处理所有与业务无关的功能。
