怎么保护你的微服务：API网关，认证和授权？

最近我正在和我的女朋友拼凑一千块拼图。经验丰富的益智建造者有一些技巧可以成功完成任务。他们遵循我们所说的“分而治之”算法。

例如，在我与女朋友建立的拼图中，我们先建立框架，然后分别收集树木，地面，城堡和天空。我们分别建造了每个街区，最后我们收集了所有更大的街区，让我们完全解谜。可能的话，如果我们没有遵循这个方法，并且我们试图逐行建立，我们可以做到，但是它会花费更多的精力和精力。我们也不会从团队中受益，因为我们一直在看同一条线，而不是进行协作和有效的工作。

这对软件是一样的！构建软件非常复杂，这就是为什么软件架构师习惯将解决方案设计成单独的模块，由单独的团队构建，然后集成到一个完整的解决方案中。但是，很多球队仍然在为这种方式而努力。小模块中的单个错误可能会导致整个解决方案失效。此外，任何组件的更新都意味着您将不得不再次构建整个解决方案。如果某个模块出现性能问题，您可能需要升级支持应用程序的所有服务器。

出于这些原因（以及其他许多原因），像Netflix，Google和Amazon这样的软件公司已经开始采用“微服务架构”。

目前还没有广泛接受的微服务定义，但对于这些特性有共识。微服务：

• 通常是自主开发的

• 可独立部署

• 使用消息通信

• 每个提供一定的业务能力。

上面的图表说明了一个典型的微服务的结构。您会注意到一些微服务将拥有自己的数据存储，而其他微服务仅处理信息。所有的微服务都通过消息传递进行通信。

虽然微服务架构使构建软件变得更容易，但管理微服务的安全性已成为一项挑战。管理传统单一应用程序的安全性与管理微服务应用程序的安全性完全不同。例如，在单片应用程序中，很容易实现管理认证，授权和其他安全操作的集中式安全模块; 由于微服务的分布式特性，拥有一个集中的安全模块可能会影响效率并且破坏架构的主要目的。同样的问题适用于数据共享：单片应用程序在“内存”应用程序的不同模块或“集中式数据库”之间共享数据，这是分布式微服务面临的挑战。

API网关

与外部世界的微服务进行通信的最明显的方法可能是使用API网关。

API网关是您的应用程序提供的所有服务的入口点。它负责服务发现（来自客户端），将来自外部调用者的请求路由到正确的微服务，并且如果外部调用者请求不同的功能，则展开给不同的微服务（想象一下带有由不同微服务提供的仪表板的网页）。如果您深入了解API网关，您会发现它们是着名外观设计模式的体现。

从安全角度来看，API网关通常会处理从外部调用者到微服务级别的认证和授权。虽然没有一种正确的方法可以做到这一点，但我发现使用OAuth委托授权和JSON Web Tokens（JWT）是微服务身份验证和授权的最高效和可扩展的解决方案。

为了进一步说明，用户首先将他的凭证发送到API网关，API网关将凭证转发给授权服务器（AS）或OAuth服务器。AS将生成JASON Web令牌（JWT）并将其返还给用户。

每当用户想要访问特定资源时，他都会从API网关请求它，并将发送JWT和他的请求。API网关将使用JWT将请求转发给拥有此资源的微服务。然后，微服务将决定是否授予用户资源（如果用户具有所需的权限）。根据实施情况，微服务可以自行做出此决定（如果它知道此用户对此资源的权限），或者只是将请求转发给环境中的其中一个授权服务器以确定用户的权限。

上述方法比传统的集中会话管理更具可扩展性。它允许每个微服务处理自己资源的安全性。如果需要集中决定，则OAuth服务器将与不同的微服务器共享权限。

如果您想在JWT的到期时间之前撤销用户的权限，则此方法面临的一个挑战是。微服务可能分布在世界各地的几个地方，API网关只是将请求转发给负责的微服务。这意味着撤销权限需要与每一个微服务进行通信，这是不实用的。如果这是一个关键功能，那么API网关可以通过向用户发送JWT的引用而不是JWT值本身来发挥关键作用。用户每次从API网关请求资源时，API网关都会将引用转换为JWT值并正常转发。如果需要撤销权限，则只会提供对API网关的单个请求，那么API网关可以终止该用户的会话。这个解决方案比JWT的价值更“分散”，所以这要取决于软件架构师和应用程序要求，以遵循这两种方法。