在我们的场景中，我们有一个内部部署设备（A）调用我们的云托管服务（B）。每个设备都属于一个客户，每个客户都有一个独特的api-key和api-secret。它们牢固地固定在设备上。
设备使用这些来通过Client Credentials流进行身份验证;令牌持续约10个小时。
服务B将请求转储到消息队列中。 服务C从队列中获取，执行一些处理并调用服务D，服务D调用服务E ......等等。
每个服务都是由https调用的独特物理边界（思考微服务）。
我们正在使用＆＃34;委托权限＆＃34;概念，以便令牌作为自定义声明传递，然后可以用于附加到链中的下一个请求。这意味着每个服务都在原始设备上运行A请求的身份验证，并且可以访问在设备A通过身份验证时创建的自定义客户特定声明。
我们还将消息中的JWT令牌作为服务B和C之间的字符串传递，当我们使用它在服务C中调用服务D时设置承载令牌时，这可以正常工作。
我的问题是，如果服务B在10小时内没有处理该消息（例如故障）。 10小时后，令牌将过期，服务B无法访问设备A用于重新请求令牌的凭据。
我认为我也需要刷新令牌，但客户端凭据流不支持此功能。然后我想到了＆＃34;作弊＆＃34;并使我的令牌持续很长时间＆＃34;但是我不确定如何在安全漏洞中使其无效。我的最后一个选择是在令牌中实际传递api-key和api-secret作为声明，然后可以用来通过链中的任何服务重新请求新令牌......但这感觉就像是一个安全漏洞等待即将发生。说实话，拥有刷新令牌也是如此，因为无论如何它都像主密码一样。
在这种情况下是否有任何建议/最佳做法？
非常感谢
答案 0 :(得分：1)
我看到两个选项
a）使令牌持久 - 但使用引用令牌。这样，您可以在需要时撤消令牌
b）实施自定义授权，允许授权客户端请求具有新生命周期的令牌副本。