让我们想一个简单的基于REST的Web服务来存储和检索JSON对象。没有任何身份验证，每个用户都可以访问任何数据。
现在让我们添加使用JWT来验证用户身份。当然，既然我们没有授权，仍然每个用户都可以访问任何东西，但至少现在我们知道谁访问了什么。
下一步：存储对象时，使用该对象保存用户的sub声明，并验证用户的sub声明是否与所请求的对象匹配，如果是，则传递它。现在我们有每个用户的授权。到目前为止，这很容易。
现在让我们添加让用户与其他用户共享对象的可能性。为简单起见，我们希望有预定义的组（即角色），我们希望让用户选择哪个组（角色）可以访问他们创建的对象。这仍然很容易，因为您有一个预定义的组列表，因此您可以让用户选择一个或多个组，并将它们附加到对象。此外，身份提供者需要以一种groups声明放入每个用户的令牌的方式进行配置，因此我们可以匹配它们。正如我们已经从本段的篇幅中看到的那样，事情变得更加复杂。
问题1：到目前为止，我是否正确处理“静态”群体，这样就可以了？
现在，让我们为用户提供自己创建群组的机会。这仍然不复杂，但我们如何使身份提供者使用动态创建的组？当然，我们不希望管理员每天更新身份提供商的配置; - ）。
问题2：我们如何处理动态创建的组？
现在，最后，让我们忘记群组，让我们说，我们希望允许用户能够简单地与其他用户共享他们的对象。这应该可以为每个对象单独配置。我们如何做到这一点？我们是否在对象上保存用户列表？如果是这样，我们究竟节省了什么？ sub声称？如果是这样，所有者用户如何知道适当的值？或者......？
并且：假设用户想要动态地将他们的朋友放入动态生成的圈子中，我们将如何做？
问题3：动态分配用户的令牌和动态创建的组如何相互协作？
答案 0 :(得分：2)
在我看来，令牌应该只包含您需要在您的资源服务器上识别用户的身份信息（ - 声明），或者在刷新时不会更改，因为您不会想要您的用户（或者你的应用程序）每次他的权限发生变化时都必须刷新他的访问权限（因为访问权限授予访问权限一段特定的时间，你不希望你的用户有权访问某些资源他/＃ 39; s丢失了自上次令牌刷新以来的访问权限，因为没有刷新令牌而只是简单地使用旧令牌。您附加到令牌的安全相关信息越多，您可能添加到系统的漏洞就越多（取决于您的令牌生存期）。
说明，我会（并且总是这样）通过他的用户ID（包含在jwt-token中）识别用户角色或组在ressource服务器上。为了实现这一点，我总是将用户身份信息附加到我的资源服务器上的当前请求，并附加＆＃34; dynamic＆＃34; -claims，如用户角色或组到身份。
通过仅添加我需要的身份信息来识别用户和用户在我的资源服务器上的权限，我倾向于在多个应用程序中使用我的身份提供者，而无需在身份提供者处理应用程序范围，所以我可以对多个独立的资源服务器使用完全相同的访问令牌。