干货分享|如何将前端代理服务器（BFF）接入身份认证(3完结篇）

续集3

前篇文章在前面发布，同学们可以自行找一下。

本篇文章将继续通过实例来详细讲解如何将前端代理服务器（BFF）接入身份认证。我们将使用一个示例应用来演示 BFF 与身份认证的集成过程。

3 在 Full BFF 中接入认证平台

本小节将介绍如何在 Full BFF 中接入身份认证平台。Full BFF 不仅接管与身份认证平台的令牌获取过程，还接管了后续与资源服务器打交道的过程。通过使用 Full BFF，前端也不需要保存身份认证平台颁发的令牌了，在这种架构下，这将由 BFF 来保存。前端和 BFF 之间通过 Cookie 维持其单独的会话。

在数字化转型浪潮中，公司或者机构组织被迫在可维护性和安全性之间做出权衡，虽然在架构中采用原始的朴素 Naive BFF 层，在实现上最简单，维护起来也更省心，但这牺牲了安全性，在今天的自动化社会中，这种妥协是不可接受的。所以我们需要一个更安全的解决方案，这就是 Full BFF。

许多拥有单页应用程序、在前端使用 access_tokens 并采用微服务架构的公司，现在正努力将身份验证转移到服务器端。这个服务器端本质上就是 Full BFF。

我们再来回顾一个目前可能会面临的问题，假设一家公司已经实现了一套如图所示的无BFF 应用架构。

在这种架构中，前端应用程序直接与身份认证平台打交道，获取令牌，然后将令牌发送到后端服务，后端服务再将令牌发送到资源服务器，获取资源。即：

1前端应用程序：

·运行在浏览器中。

·通过将未经过身份验证的用户转到身份提供者来发起对用户的验证。

·当用户验证之后，前端单页面应用程序发起令牌请求。

·前端单页面应用将令牌随着 Authentication 头发送到后端服务进行 HTTP 调用。

2身份提供者：

·是 OpenID Connect 服务器。

·颁发令牌。

·验证用户的凭据，即用户在此处登录。

3API/微服务：

·通过令牌保护。典型的是只有在令牌有效时才允许访问 API。

·API 应用一个规则来决定一个用户是否已经被授权来访问/查看资源。换句话说，微服务，会实施访问控制策略。

这种架构有什么问题呢？下面来看看。

1）在前端进行令牌交换暴露了不必要的攻击向量

在这样的架构下，当用户登录时，授权码会发送到前端。前端必须拿这个授权码来换取令牌。

理论上没有办法分辨是谁在拿着授权码换取令牌。为了确保将令牌发送给想要发送的接收方，就需要使用客户端密钥。但是在这个架构下，没有使用客户端密钥。

2）令牌可以被盗用

由于令牌存储在前端，理论上很容易被盗用。

由于以上架构有着这样的问题，因此我们更推荐下面的方案。一般来说，要缓解上面提到的架构的安全风险，就需要将验证环节转移到服务器端。

这样的结果就是，解决方案架构会变得更加复杂（这也是在采纳该方案时需要仔细权衡的原因）。

为了能够在服务器端验证用户，就需要一个能够跟踪用户会话的组件，这个组件就是 Full BFF，如图所示。

上图的架构图包含：

1浏览器端的单页面应用。

·运行在浏览器端。

·和 API 处于同一个域名下。

·并不是用户验证的发起方。

2 BFF。

·负责托管单页面应用资源（index.html 和/dist 目录）。

·暴露 API。

·拥有 HTTP 会话状态。

·是验证用户的发起方（将用户重定向到身份提供者）。

3身份提供者。

·是一个 OpenID Connect 服务器。

·颁发令牌。

·验证用户的凭据，即用户在此处登录。

4API/微服务。

· 被令牌保护。一般来说，只有在令牌有效时才允许访问 API。

·API 应用一个规则来决定一个用户是否已经被授权来访问/查看资源。换句话说，微服务，会实施访问控制策略。

为什么 Full BFF 架构会更安全呢？主要有以下两个原因：

（1）令牌交换发生在服务器端。

对于攻击者来说，没有任何方式观察到 BFF 是怎么获取到令牌的，从而极难进行干预。

同时，由于验证过程也发生在服务器端，因此在交换令牌的过程中可以安全地包含客户端密钥。

这就意味着身份提供者可以验证究竟是谁正在获取令牌。

（2）更安全的会话管理。

如果要将令牌保存在浏览器端，一般就是保存在一个安全 Cookie、本地存储或者会话存储中。

如果攻击者找到了办法复制它们，就基本上劫持了会话。要防止这样的情况，前端就需要实现所有这些机制：预防会话劫持、防止 CSRF 攻击、防止 XSS 攻击等。

实现会话管理最好的方式是不要自行实现。微软（或者其他大型公司）已经为我们完成了这向工作。

工作原理分析：简单来说，BFF 就是一个反向代理服务器。但是 Full BFF 强调它不仅将流量传递到下游领域服务，它还在转发请求时添加 Authentication 头部。

Full BFF 会处理两种类型的请求。多数请求是由单页面应用发起的 API 请求。BFF 处理 API 请求的流程如图所示。

Full BFF 会将请求转发到 API，同时将令牌添加到 Authentication 头部。API 会验证令牌，然后返回响应。

Full BFF 还有网站托管能力，这意味着用户可以通过浏览器访问该 BFF。当用户浏览至该 BFF时，有一个特殊的端点：/login 端点。通过该端点，用户得以验证。验证用户的处理流程可以使用图来展示。

完结啦！BFF 的发展历程，以及每个阶段的 BFF 如何接入身份认证平台，本篇文章就已经全部讲清楚了。以后还会为大家带来喜欢的干货文章，请多多关注哦！

本文摘自《数字身份认证技术与实践》，获出版社和作者授权发布。

数字身份认证技术与实践——jd