权限设计系列「认证授权专题」微服务常见安全认证方案

Posted 2022-12-28 洛神灬殇

HTTP 基本认证

HTTP Basic Authentication（HTTP 基本认证）是 HTTP 1.0 提出的一种认证机制，这个想必大家都很熟悉了，不再赘述。

HTTP 基本认证的过程如下

1. 客户端发送HTTP Request给服务器。
2. 因为Request中没有包含 Authorization header，服务器会返回一个 401 Unauthozied 给客户端，并且在 Response 的 Header “WWW-Authenticate” 中添加信息。
3. 客户端把用户名和密码用BASE64加密后，放在Authorization Header中发送给服务器， 认证成功。
4. 服务器将Authorization Header中的用户名密码取出，进行验证，如果验证通过，将根据请求，发送资源给客户端。

基于 Session 的认证

基于Session的认证应该是最常用的一种认证机制了。用户登录认证成功后，将用户相关数据存储到Session中。

• 单体应用架构，默认Session会存储在应用服务器中，并且将 Session ID 返回到客户端，存储在浏览器的Cookie中。

• 分布式的架构，Session 存放于某个具体的应用服务器中自然就无法满足使用了，简单的可以通过 Session 复制或者 Session 粘制的方案来解决。

Session的复制机制

Session 复制依赖于应用服务器，需要应用服务器有 Session 复制能力，不过现在大部分应用服务器如 Tomcat、JBoss、WebSphere 等都已经提供了这个能力。除此之外，Session 复制的一大缺陷在于当节点数比较多时，大量的 Session 数据复制会占用较多网络资源。

Session 粘滞是通过负载均衡器，将统一用户的请求都分发到固定的服务器节点上，这样就保证了对某一用户而言，Session 数据始终是正确的。

不过这种方案依赖于负载均衡器，并且只能满足水平扩展的集群场景，无法满足应用分割后的分布式场景。

微服务架构的认证能力

在微服务架构下，每个微服务拆分的粒度会很细，并且不只有用户和微服务打交道，更多还有微服务间的调用。这个时候上述两个方案都无法满足，就要求必须要将 Session 从应用服务器中剥离出来，存放在外部进行集中管理。可以是数据库，也可以是分布式缓存，如 Memchached、Redis 等。这正是 David Borsos 建议的第二种方案，分布式 Session 方案。

基于 Token 的认证

随着 Restful API、微服务的兴起，基于 Token 的认证现在已经越来越普遍。Token 和 Session ID 不同，并非只是一个 key。

Token 一般会包含用户的相关信息，通过验证 Token 就可以完成身份校验。像 Twitter、微信、QQ、GitHub 等公有服务的 API 都是基于这种方式进行认证的，一些开发框架如 OpenStack、Kubernetes 内部 API 调用也是基于 Token 的认证。基于 Token 认证的一个典型流程如下：

用户输入登录信息（或者调用 Token 接口，传入用户信息），发送到身份认证服务进行认证（身份认证服务可以和服务端在一起，也可以分离，看微服务拆分情况了）。

1. 身份验证服务验证登录信息是否正确，返回接口（一般接口中会包含用户基础信息、权限范围、有效时间等信息），客户端存储接口，可以存储在 Session 或者数据库中。

2. 用户将Token放在 HTTP 请求头中，发起相关 API 调用。

3. 被调用的微服务，验证 Token 权限。

4. 服务端返回相关资源和数据。

基于 Token 认证的好处如下

• 服务端无状态：Token 机制在服务端不需要存储 session 信息，因为 Token 自身包含了所有用户的相关信息。

• 性能较好，因为在验证 Token 时不用再去访问数据库或者远程服务进行权限校验，自然可以提升不少性能。

• 支持移动设备。

• 支持跨程序调用，Cookie 是不允许垮域访问的，而 Token 则不存在这个问题。