Netflix 如何解决身份验证问题？.docxVIP

Netflix 如何处理身份验证问题？ 最后，Netflix 是一个允许会员管理他们的 DVD 队列的网站。后来，网站添加了流媒体内容的功能。流媒体设备消灭的时间稍晚一些，但这些设备最后的力量有限。随着时间推移，设备的功能和功能不断提高，以前只能在网站上访问，现在可以通过流媒体设备访问。Netflix 服务的规模快速增长，支持超过 2000 种设备类型。 现在，支持这些功能的服务需要理解多个令牌和平安协议，以便识别用户和设备，并授权对这些功能的访问，这添加了服务的负担。整个系统相当简单，并且开头变得脆弱。此外，边缘层的架构正在演化为 PaaS（平台即服务）模型，我们需要做出一些困难的打算，包括如何以及在何处进行身份令牌处理。 简单性：多个服务处理认证令牌 为了说明系统的简单性，下图呈现了在做出本文引见的更改之前，用户的登录流程： 从大的方面说，这个（大大简化的）流程涉及如下步骤： ●用户输入他们的凭据，Netflix 客户端将凭据连同设备的 ESN 一起传送到边缘网关，即 Zuul。 ●Zuul 将用户调用重定向到 API/login 端点。 ●API 服务器编排后端系统来验证用户。 ●假如验证成功，API 服务器就向上游发送一个 cookie 响应，包括 customerId（一个 Long 值）、ESN（一个字符串）和一个过期指令。 ●Zuul 将 cookie 发回给 Netflix 客户端。 这个模型有一些问题，比如： ●外部有效的令牌是在验证栈的深处生成的，需要一直向上传播，这可能导致记录不当或管理不当。 ●上游系统必需重新打开令牌来识别用户登录，并可能管理多个并行的身份数据结构，这些数据结构很简约消灭不同步。 多个协议 令牌 上面的示例显示了一个处理一种协议（HTTP/S）和一种令牌类型（cookie）的流。Netflix 流媒体产品中使用了多种协议和令牌，汇总如下： 这些令牌被 Netflix 流媒体生态系统中的多个系统消费，并可能被它们更改，例如： 让情况变得更简单的是，有多种方法可以将这些令牌或其中包含的数据从一个系统传输到另一个系统。在某些情况下，令牌被破解，身份数据元素被提取为简约的原语或字符串，用于 API 调用，或通过恳求上下文头从一个系统传递到另一个系统，甚至作为 URL 参数。系统中没有适当的检查来确保令牌或其中包含的数据的完整性。 Netflix 的规模 与此同时，Netflix 的运营规模呈指数级增长。如今，Netflix 拥有 2 亿多订阅用户，每月有数百万活跃设备。我们每秒处理超过 250 万个恳求，其中很大一部分恳求需要某种方式的身份验证。在旧有的架构中，每个恳求都会导致一个 API 调用来进行验证，如下所示： EdgePaas 半路宰出 使情况进一步简单化的是，Edge 工程团队正在从旧的 API 服务器架构迁移到新的基于 Paas 的方法。当我们迁移到 EdgePaaS 时，前端服务从基于 Java 的 API 移到了 BFF（为前端应用开发的后端），也就是 NodeQuark，如下图所示： 这个模型使前端工程师能够在核心 API 框架之外拥有和操作他们本人的服务。然而，这又带来了另一层简单性——这些 NodeQuark 服务将如何处理身份令牌？NodeQuark 服务是用 JavaScript 编写的，终止像MSL这样简单的协议既困难又铺张，由于要复制令牌管理的全部规律。 让我们总结一下 总之，我们发觉，我们用于处理大规模的身份验证和身份令牌的处理方案简单而低效。我们有多种身份令牌类型和来源，每种都需要特殊处理，其规律被复制到不同的系统中。关键身份数据以不全都的方式在整个服务器生态系统中传播。 边缘身份验证服务来救场 我们意识到，为处理这个问题，需要一个统一的身份模型。我们需要在更上游的地方处理身份验证令牌（和协议）。为此，我们将身份验证和协议终止移到网络边缘，并新建了一个具有完整性爱护的、令牌无关的身份对象，它可以在整个服务器生态系统中传播。 将身份验证移到边缘 考虑到我们的目标是提高平安性和降低简单性，并最终供应更好的用户体验，我们的策略是将设备身份验证操作、用户身份识别和身份验证令牌管理集中到服务边缘。 从大的方面来说，Zuul（云网关）将成为令牌检查和有效负载加密/解密的终止点。假如 Zuul 无法处理这些操作（一小部分），比如令牌不存在，需要更新，或者无效，Zuul 会将这些操作托付给一套新的边缘身份验证服务来处理加密密钥交换和令牌创建或更新。 边缘身份验证服务 边缘身份验证服务（EAS）既是一种将设备和用户身份验证和识别移至云边缘的架构概念，也是一套为处理每种令牌类型而开发的服务。 在功能上，EAS 是一系列运转在 Zuul 中的过滤器，它可以调用外部服务来支持它们的域