我计划在我的微服务上实现JWT认证,以实现零信任架构。用户将通过前端微服务生成JWT令牌.每个后续请求都将包含这个JWT,该JWT将被转发到后端服务,这样服务就可以自己对用户进行身份验证,而不是从前端服务中获取一个简单的用户id。该方案在两种情况下失败。
在这两种情况下,用户都无法通过登录凭据生成新的JWT令牌。除了JWT之外,我应该实现一个特定于时间和目的的令牌来解决这些问题,还是有更好的选择?
发布于 2019-12-10 15:51:40
tl/dr:后端可以接受用户id作为零信任体系结构的一部分。更重要的是,您的服务必须对后端进行身份验证,后端的适当部分应该只接受来自服务的请求(而不是来自最终用户的请求)。因此,您的问题是试图将终端用户的auth令牌用于最终用户不应该直接访问的服务。让您的服务使用后端进行身份验证,然后传递用户id是非常好的。
我认为关键是,您混淆了您的一些后端系统的“用户”是谁。
这一点在第二个示例中是最清楚的:删除一个非活动用户。这是一个纯系统的过程。用户自己永远不会触发此操作。后端是执行操作的“用户”,即使用户帐户受到影响。因此,首先使用用户的访问令牌删除用户是没有意义的。这并不意味着用户会向后端发出这些请求。事实上,无论如何,用户不应该能够访问这些端点。如果某个用户设法访问后端试图删除他们的帐户,那么他们的访问令牌应该被拒绝--这个端点只供系统使用,(大概)不供用户自己删除。因此,通过使用用户的auth令牌来执行这些系统操作,您将身份验证为错误的"person“。
第一个示例的情况比较模糊,因为是用户发出的初始请求触发了后面的操作。然而,总体情况似乎还是一样的--后端进程正在对用户的数据采取行动。这个系统的“用户”不是实际的最终用户,而是您自己系统的一部分。它只是代表你的用户行事。
简而言之,如果您有不打算由用户直接调用的后端服务,那么这些服务不应该接受用户的访问令牌。
那么,如何实现零信任系统呢?当然,就像你试图这么做的方式一样--你只是在鉴定错误的人。并不是用户需要对后端进行身份验证,而是无论服务使用什么后端都需要验证自己。对于JWT来说,这可能是也可能不是。这可能是一个简单的问题,只有"cron“服务才知道身份验证令牌,并且它使用它来验证自己的后端。这些细节取决于你。
然而,我认为这是唯一真正的答案。这些服务需要自己用后端的相关部分进行身份验证,后端的这些部分应该只接受来自经过身份验证的服务的请求--而不是来自具有最终用户JWT的最终用户的请求。显然,您必须为您的服务构建身份验证方法,以便在相关的情况下解决凭据轮换问题。但是,由于您不会使用用户的密码作为该过程的一部分,所以这并不是一个问题。
发布于 2023-01-26 21:44:14
实际上,良好的零信任依赖于背对背身份验证+用户签名授权。
每个后端只与允许的后端集(API)交互的服务身份验证授权方。预期在服务网络/不相关后端中重用来自不受信任客户端的客户授权的风险。它还允许您创建权威服务,这些服务可以代表用户执行某些操作。创造持久的工作岗位是一种常见的情况。
令牌使用非对称加密技术。每个服务都有一个用于签名服务令牌的私钥。
服务令牌结构:
每个后端指定允许的源列表,每个源被映射到公钥以验证令牌。
所有背对背查询都是使用服务令牌执行的。
一旦我们在服务通信中实现了零信任原则,我们现在希望限制后端在没有实际用户发出命令的情况下模拟用户。这就是用户令牌和您的方案出现的地方。
用户在前端服务上发起呼叫,该呼叫生成要依次在后端服务上执行的步骤的长列表。JWt令牌最终将过期,步骤序列将停止,因为后端服务不会使用expried令牌对来自前端的进一步请求进行身份验证。
授权执行“一长串步骤”的后端通过使用客户端的公钥检查JWT签名来验证用户是真实的。一旦签名有效,它现在就可以安排操作。
通过赋予服务一个模拟特权,我们基本上将用户身份验证替换为服务身份验证。如果使用带有用户密钥的加密存储,则服务必须在用户交互时准备流程所需的所有数据。
对于长时间(或类似cron)的作业,服务可能被授予在特定操作范围内模拟用户的权限。在此场景中,用户的JWT令牌授予作业的特定操作、规律性和参数,并且永不过期。通过向JWT发出和唯一的标识符并维护已撤销的标识符列表或提供刷新令牌的能力,实现撤消策略是值得的。
https://security.stackexchange.com/questions/222543
复制相似问题