我是.NET微服务架构的新手，现在我正在实现一个用于学习管理的.NET应用程序，它由几个微服务和一个API网关- Ocelot组成。
所以认证是在网关中处理的（bearer token）对于授权部分，我有一些担心：我有一个专用的微服务，它保存用户的角色权限和范围，我在想，在网关中，每个请求都有一个中间件来获取用户权限和范围，并将它们添加到请求头中。然后在每个控制器端点上的微服务层上，我使用一个专用的TypeFilterAttribute，其中我传递一个字符串列表和一个可选的操作符，可以是或/和。在OnAuthorization方法中的自定义过滤器中，我提取用户的权限并应用验证逻辑，同时考虑所需的权限和通过自定义属性传递的操作符。对于网关，我还可以实现用户权限的缓存。
这是一个可靠的解决方案吗？也许在请求头中传递权限和作用域不是一个好主意，因为它可能会超过大小限制，我假设只要网关是公开的，就没有风险。你看到或使用其他替代方案吗？
1条答案
按热度按时间ac1kyiln1#
为了简单起见，我在这里假设特权类型的数量小于或等于64，在这种情况下，您可以将您的特权表示为数字的位。
如果你的数字是用64位表示的，那么这就是8个字节，只需要几个数字。你可以通过将其压缩为base64来进一步压缩它，使其更短。
现在，如果您有超过64种特权类型，那么您可以将它们分解为几个数字，并通过base64将它们压缩在一起。
然而，这里存在一个安全问题。如果我作为用户可以将特权作为承载令牌发送，并且假设我弄清楚了特权是如何表示的，那么我可以使用权限较低的用户登录，并在请求中声明该授权者是您信任的应用程序，并且我拥有超级管理员权限。
因此，您的方法不是很安全，更有意义的做法是将传递到非常安全的临时有效令牌（JWT）中的整个数据进行编码，该令牌在首次使用时完全有效，或者您避免发送特权，相反，您的客户端应用程序将请求发送回服务器，该服务器是您的特权的真实来源（IDP），这将保证从正确的位置接收特权，并且您甚至不必担心响应的大小。