详解微服务中的三种授权模式( 二 ) 作者|GrahamKaemmer译者|Rayden审校

你可以将数据模型和逻辑分开，这样文档服务就可以控制向哪个角色授予哪些文档相关的权限（管理员可以编辑，成员可以读取，等等），然后用户服务公开一个API来获取组织中用户的角色。有了这个API ，权限检查可以像这样进行:

文章图片
有一个合理的论点认为最简单的解决方案就是最好的方案，在这里它通常是没问题的。根据我的经验，这通常是当团队开始转向微服务并想让用户授权正常工作的情况下所使用的解决方案。它完成了工作，而且不需要任何额外的基础设施。
当服务或团队数量增加、授权逻辑变得更复杂或面临更严格的性能要求时，此模式开始出现问题。要让该模式正常工作，任何新服务的开发人员都需要知道如何从用户服务中获取角色数据，而用户服务本身必须扩展以满足这种需求。随着服务依赖关系的增加，该模式可能会增加不可预测的延迟和重复请求。也许引入一个单独的“文件夹”服务就会导致系统需要通过服务之间的相互调用来进行权限检查：

文章图片
尽管有变得混乱的风险，但这种模式可以让你走得很远。无需部署和维护额外的授权基础设施可能是一个巨大的优势，如果具有数据的服务能够处理来自需要数据的服务的负载，那么将它们串在一起就是一个很好的解决方案。
有一些团队遵循这种通用模式，但他们认为应该用某种专门的授权服务替换所有这些请求流，我和这些团队有过交谈。我总是问他们真正的问题是什么。如果问题是时延，也许在正确的位置添加缓存可以解决这个问题。如果授权逻辑在服务中变得越来越混乱，那么可能需要强制采用标准策略格式。（Oso是一个解决方案；还有其他解决方案。）
但是，如果问题是你的数据模型变得过于复杂，或者你在重复实现相同的api ，或者权限检查需要与太多不同的服务通信，那么也许是时候重新考虑架构了。
模式2：请求网关
解决授权数据问题的一个优雅的解决方案是将用户角色包含在对服务（这些服务可能需要做出授权决策）的请求中。如果文档服务在请求中获得有关于用户角色的信息，那么它可以基于这些信息做出自己的授权决策。

文章图片
在这种模式中， “网关”位于API和其最终用户之间。网关可以访问用户信息和角色信息，它可以在将请求传递给API本身之前将这些信息附加到请求中。当API接收到请求时，它可以使用来自请求的角色数据（例如在请求头中）来检查用户行为是否被允许。
网关通常同时负责身份验证和授权。例如，网关可能使用Authorization头对特定用户进行身份验证，然后另外获取该用户的角色信息。然后网关将带有用户ID和角色信息的请求代理给下游服务（上面示例中的文档服务）。

文章图片
网关模式的主要好处是其架构简单。它使下游服务（如文档服务）的开发人员不必关心角色数据来自哪里。授权数据在请求中始终是可用的，因此可以立即执行权限检查，而不需要任何额外的调用。
请注意，在这里使用明文头信息开辟了新的攻击途径——你需要确保恶意客户端不能注入它们自己的头信息。作为一种替代方法，用户角色或其他访问控制数据可以包含在他们的身份验证令牌中，通常表示为JWT 。