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

Posted 2023-03-31 SinbadZhuang

认证，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的压力，是一种高性能的、可扩展的架构，适用于大部分对安全要求不太敏感的微服务场景。

Day915.安全认证架构演进：微服务阶段 -SpringBoot与K8s云原生微服务实践

安全认证架构演进：微服务阶段

Hi，我是阿昌，今天学习记录的是关于安全认证架构演进：微服务阶段的内容。

在上一篇：《安全认证架构演进：单块阶段》讲了针对单块服务阶段的安全认证架构发展演技过程，到现在的微服务阶段;

在不同的阶段会有不同阶段的问题，微服务阶段也是一样。

一、微服务认证鉴权挑战

因为业务的形态发生了多样化，出现了各式各样的，如WebMVC引用、无线应用、前后分离H5应用等，那就需要改造认证鉴权的方式，让它是支持上面出现各式各样的引用。

那如上出现了许多的挑战：

1. 后台引用和服务众多，如何对每一个服务和引用鉴权
2. 前端的用户引用众多，针对每一个引用都需要搞一套独立的鉴权方案，成本和开发时间过大
3. 需要考虑SSO单点登录，减少用户的重复登录操作

---

二、2.0阶段

上面的分析得出的结果，之前的1.5阶段基于session&cookies的方式需要被改变，不能沿用，但是可以借鉴其思想，进一步的延伸改造，并可以针对微服务的场景进行针对扩展。

2.0阶段最大的变化是将登录认证鉴权的逻辑抽取成了独立的一个专门的auth service服务来进行处理，它这个服务统一处理登录认证、令牌颁发、会话管理校验等职责；另外2.0阶段也引入了Token令牌的服务调用校验健全的主要机制。

在2.0阶段中采用“透明令牌”：令牌是一个无异议的随机字符串，当是这个令牌和一次登录的会话是相关联的，后续可以通过这个透明令牌去鉴权服务专门的校验权限，或查询对应用户的数据信息，所以这个令牌又可以成为“引用令牌”，它本身不包含数据，它是鉴权服务上用户信息引用的一个标识符，类似与之的sessionId。

1. 用户登录会统一走鉴权服务authService统一完成，用户通过某个客户端。 输入用户密码登录，请求鉴权服务authService处理。authService查询数据，如果通过校验，这建立一个用户会话session，存在过期的时间，可以存放到数据库中，也可以存储在redis缓存中
2. authService成功会返回Token给客户端，客户端可临时存储这个Token令牌。
3. 客户端向后端微服务发出请求，这个请求会带上本地存储的Token令牌，携带的方式可以在HttpHeader等上。
4. 微服务接收到客户端发来的请求，并获取到客户端发来的Token令牌，微服务会发起请求到authService校验服务去校验客户端发来的Token令牌是否能通过校验。
5. 在后续微服务需要用到用户信息时，微服务可以用Token令牌去向authService鉴权服务去获取对应Token令牌对应的用户信息。
6. 调用完成，响应返回客户端。

2.0阶段类似1.5阶段中集中状态会话方案的改造和扩展，它将用户鉴权认证授权颁发Token令牌都统统封装到了统一的服务authService当中，使的职责跟清晰；且引入的令牌的机制，可以做到SSO单点登录机制。

但是也存在一定的问题，如每个微服务都需要写一些认证鉴权的逻辑，使得对应业务的开发方也需要写对应的鉴权逻辑，增加的开发成本；另外将认证鉴权逻辑分散开，会具有用户信息安全的风险；也存在开发不够规范。

---

三、2.5阶段

为了解决上面的一些问题，2.5阶段引入了网关模块，他在微服务调用之前进行做调用的分发和代理。

2.5阶段与上面的2.0阶段大致相同，唯一不同的增加了网关的模版。

因为引入了网关作为微服务的入口，那网关就可以统一的去authService上去做健全和认证对其Token令牌进行校验。
网关向authService服务去用Token令牌可以获取到用户信息，后续可以将用户信息直接去通过调用传递给后面的微服务。
后台的微服务可以直接通过网关获取用户的信息，后台的网关和微服务之间是相互信任的，所以微服务自己直接是不需要再重复的去authService去鉴权和认证。

通过引入网关做统一的认证鉴权后，大大简化了后台微服务开发方，让他们只针对开发后台的业务逻辑，并不需要去担心用户鉴权的内容，这样子就开发会更加的规范，且更简单；

---