该模型可以在不依赖核心API框架的前提下让前后端工程拥有和操作各自的服务。但这也引入了另一层复杂性，即这些NodeQuark服务如何处理身份令牌？NodeQuark服务是用JavaScript编写的，废除了像MSL这样复杂又浪费的协议，这些协议会复制所有令牌管理的逻辑。
做个总结，在大规模场景下，发现我们使用了一个复杂且低效的方案来处理认证和身份令牌。我们有多种身份令牌类型和资源，每种身份令牌又需要不同的处理，各个处理逻辑被复制到了多个系统中。关键身份数据以不一致的方式在整个服务器生态系统中传播。
使用边缘认证解决问题我们意识到，为了解决这个问题，需要一个统一的身份模型，在上游进一步处理身份验证令牌（和协议）。我们通过将认证和协议终结转移到边缘网络，然后创建一个新的完整性保护的且令牌无关的对象，使该对象在整个服务器生态系统中传播。
将认证转移到边缘注意，我们的目标是提升安全性，并降低复杂度，进而提供更好的用户体验，我们就如何将设备身份验证操作以及用户标识和身份验证令牌管理集中到服务边缘制定了相应的策略。
从上层看，Zuul(云网关)作为令牌检查和载荷加密/解密的终结点。这种情况下，Zuul可以处理这些操作(一小部分)，例如，如果没有出现令牌，则需要更新，否则视为无效。Zuul会将这些操作委派给一组新的边缘身份验证服务，用来处理加密密钥交换以及令牌的创建或更新。
边缘认证服务边缘认证服务(EAS)是一个架构理念，包含将设备和用户的认证和身份验证从栈转移到云边缘，以及用于处理令牌类型而开发的服务套件。
EAS是运行在Zuul中的一系列过滤器，可能会调用外部服务来支持域(domain)，如调用一个服务来处理MSL 令牌或Cookies的其他令牌。EAS涵盖了为只读令牌创建"Passport"(稍后会涉及到)。
EAS处理请求的基本模式如下：
对于每个进入Netflix 服务的请求，Zuul中的EAS入站过滤器会检查设备客户端提供的令牌，然后将请求转发到"Passport"检查过滤器(Passport Injection Filter)，或某个认证服务进行处理。Passport Injection Filter会生成一个令牌无关的身份，然后使用该身份在剩余的服务生态系统中传播。在响应路径上，在边缘认证服务的协助下，EAS出站过滤器会生成需要发送到客户端设备的令牌。
现在系统架构的格式如下：
注意令牌永远不会越过边缘网关/EAS边界。MSL安全协议会在边缘网关上终结，且所有的令牌会在网关上打开，然后以一种令牌无关的方式在服务生态系统中传播身份数据。
在新的处理路径上，Zuul能够处理大量有效且未过期的令牌，边缘认证服务处理剩余的请求。
EAS服务具有容错性，例如在Zuul标识Cookies有效但已过期，且对EAS的续约调用失败或某些潜在的错误情况下：
这种失败场景下，Zuul中的EAS过滤器将会容忍这种错误，并允许解析后的身份继续传播，并在下一次请求时重新调度续约调用。
令牌无关的身份(Passport)使用简单的可变身份结构是远远不够的，因为这样会导致服务到服务间传递的身份缺少足够的信任。此时需要令牌无关的身份结构。
我们引入了一个称为"Passport"的身份结构，它允许以统一的方式传播用户和设备身份信息。Passport也是一种令牌，但相比使用外部令牌，使用内部结构能带来很多好处。然而，下游系统仍然需要访问用户和设备身份。
Passport 是一种由边缘网关为每个请求创建的短生命的身份结构，即它的生存时间取决于请求的生命周期，且仅在Netflix生态系统内部有效。Passport由Zuul通过一组身份过滤器生成。一个Passport包含用户&设备身份，格式为protobuf，其完整性由HMAC保证。
Passport 结构