opaque随机数（通常为128位，有时为64位），我们将其称为AUTH_ID。令牌加有效期由此AUTH_ID编制索引。您可以将AUTH_ID存储在客户端浏览器的会话中，或者返回带有令牌的令牌。如果已经存在设计，那么您将需要创建一种方法来搜索数据库以匹配传递给您的令牌。如果用户实际上不需要令牌，请给他们AUTH_ID。当客户端向您发出请求时，请从客户端会话中提取AUTH_ID并查找令牌。如果令牌即将过期，请刷新令牌并存储新令牌。然后继续客户的请求。
我有一个中央“枢纽”，其中包含多个组织的数据，每个组织都包含多个用户。组织和用户以及“ client_credentials”在“项目”下分组在一起。用户可以使用“密码”授权类型进行身份验证，并根据OAuth2规范获得访问和刷新令牌。两者都是JWT。
我遇到的问题是以“正确”的方式将刷新令牌正确地分配给相关用户，以便我可以发布具有正确内容的JWT access_token。
当请求原始令牌时，我同时传递并验证了客户端凭据和用户的用户名/密码。会生成两个相同的（到期时间除外）令牌，其中包含user_id和其他位。一种用于访问，一种用于刷新。
因此，当验证刷新令牌时，我看到（除非我的理解是错误的）使这种情况发生的几种方法：
在初始请求上，针对用户的数据库记录存储refresh_token，并基于与客户端凭据以及此存储的令牌的关联进行查找。或：
任何指导都是正确的方法，还是有人有其他选择吗？
我有一个中央“枢纽”，其中包含多个组织的数据，每个组织都包含多个用户。组织和用户以及'client_credentials'在'...
opaque随机数（通常为128位，有时为64位），我们将其称为AUTH_ID。令牌加有效期由此AUTH_ID编制索引。您可以将AUTH_ID存储在客户端浏览器的会话中，或者返回带有令牌的令牌。如果已经存在设计，那么您将需要创建一种方法来搜索数据库以匹配传递给您的令牌。如果用户实际上不需要令牌，请给他们AUTH_ID。当客户端向您发出请求时，请从客户端会话中提取AUTH_ID并查找令牌。如果令牌即将过期，请刷新令牌并存储新令牌。然后继续客户的请求。
刷新令牌的内容是特定于实现的。这意味着，如果您要依赖于有关刷新令牌（或访问令牌）的信息，则必须将该信息与令牌一起存储。一些令牌是Signed-JWT，一些是不透明的。