【微服务】网站安全认证架构演进

认证，Authentication，识别你是谁。用来识别某个用户是否是注册过的合法用户。
授权，Authorization，识别你能做什么。用来识别某个用户是否有某方面的权限。

单体架构阶段

Auth V1版本

v1版本使用了传统的Session+Cookie的形式。当用户请求登录后，服务器会校验用户名和密码，校验通过后会向Session中添加一条记录，然后将SessionId添加到Cookie里面返回给浏览器。

后续用户的访问操作会携带SessionId，Web服务器就可以根据SessionId去Session中检查，以判断用户是否登录及登录状态是否过期等。

存在的问题
Session记录只会在登录的那一台服务器上存在，而后台web服务是一个集群，前置的Nginx会将请求进行基于负载均衡策略的转发，所以可能会出现用户间歇性退出的情况。

解决方式
黏性Session架构。

Auth V1.1 ~ Sticky Session

由Nginx维护SessionId和Web服务器之间的关联，不管那一次请求，Nginx会将请求转发给对应的Web服务器进行处理，以便保证在会话期间的Session绑定。

存在的问题

• 稳定性：黏性会话会将用户会话绑定到某个服务器上，如果我们要对这个服务器进行一些升级或改造又或服务器延迟或宕机，那么此服务器上的一波认证用户信息就会瞬间消失，用户必须重新登录。
• 扩展性：黏性会话使得Web服务器和Nginx负载均衡服务器上都保存了状态，整体上属于一个有状态架构。随着流量的增长，这些状态同时给Web服务器和负载均衡器都会带来较大的压力。和无状态的应用架构比起来，这种有状态的应用架构比较难以扩展。

解决方式

• 会话同步复制：即各个Web服务器之间同步Session，但是会引入复杂性，整体的性能较低。
• 无状态会话：即Session数据不存在服务器端，而是存在浏览器端，但是存在数据泄露风险，且浏览器端对于Cookie的大小有限制（4KB）。
• 集中状态会话：即将Session集中存储在某个存储中，比如Memcached或Redis这种高性能缓存中。

Auth V1.5 ~ Centralized Session

Web服务器和Nginx服务器不再存储会话状态，转而交由Redis进行统一存储，从而提高了稳定性和扩展性。
对于Redis来说，也可以采用高可用集群方案，业界也有很多可扩展的实践案例。

微服务架构阶段

Auth 3.0 ~ Auth Service + Token

将登录认证抽取为一个独立的API微服务AuthService，拥有一个独立的UserDB。
这个服务统一承担登录认证、用户校验、令牌颁发等职责。
还引入了Token作为服务调用认证鉴权的主要凭证。token是一个透明令牌，也称为引用令牌，每个微服务拿到令牌，都可以去AuthService进行认证鉴权。

存在的问题

• 每个微服务都需要实现部分认证鉴权的逻辑，使得微服务开发方无法聚焦于业务逻辑的开发。
• 认证鉴权逻辑分散在每个微服务当中，一方面会带来不规范容易出错的问题，另一方面也会有潜在的安全风险（比如忘记校验令牌）

解决方式
引入网关层，进行统一的认证鉴权

Auth 3.5 ~ Token + Gateway

该架构将每个微服务都要进行的部分认证鉴权的逻辑从微服务转移到了网关中。即网关处负责拿到令牌向AuthService进行鉴权，通过后再将请求转发到后端的微服务，微服务不再包含任何认证鉴权的逻辑。
总体上，通过引入网关进行令牌的鉴权之后，大大减少了后端微服务开发方的职责，使得他们更专注于微服务的业务逻辑的开发。此外，引入网关之后，网关可以统一处理登录客户端的校验，也便于实现SSO单点登录，也为后续的微服务化和业务成长提供了基础。

存在的问题
当网站的访问流量比较大的时候，对Auth Service的压力比较大，Auth Service可能会成为性能和扩展性的瓶颈，需要严格的监控，做好HA，做好按需扩容。

解决方式
对于某些对安全不是很敏感的微服务，集中状态校验就会显得过于笨重。此时微服务可以采用基于JWT令牌的无状态的认证鉴权架构，

Auth 3.6 ~ JWT + Gateway

Auth Service颁发的令牌不再是透明令牌，而是JWT令牌。
由于JWT令牌是自包含数据和签名的，网关就不再需要到Auth Service上进行集中的校验。
这种做法简化了架构，降低了Auth Service的压力，是一种高性能的、可扩展的架构，适用于大部分对安全要求不太敏感的微服务场景。