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