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

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 方案。

【权限设计系列】「认证授权专题」微服务常见安全认证方案_第1张图片

基于 Token 的认证

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

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

【权限设计系列】「认证授权专题」微服务常见安全认证方案_第2张图片

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

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

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

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

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

基于 Token 认证的好处如下
  • 服务端无状态:Token 机制在服务端不需要存储 session 信息,因为 Token 自身包含了所有用户的相关信息。

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

  • 支持移动设备。

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

你可能感兴趣的:(实战指南之分布式/微服务,微服务,架构,java)