我正在为移动应用程序构建 REST API 后端。在我们的设计选择中，我们决定让 OAuth2 提供商处理登录安全性。
但是，我不确定访问令牌的最佳实践是什么，我从 OAuth2 提供程序获取。
情况是，当用户登录时，我从 OAuth2 提供者那里获得了一个访问令牌。每次移动应用程序向我的后端发出请求时，我都需要使用这个令牌。因此，我可以针对 OAuth2 提供者进行验证，以查看令牌是否仍然有效。
我知道我要创建一个 JWT，并将它交给移动应用程序，它会在每次发出请求时使用它。
现在我的问题是，我是否应该将我从 OAuth2 提供程序获得的访问令牌存储在 JWT 中作为声明。
或者我应该将它存储在数据库中，并将其与用户 ID 连接，我将存储在 JWT 声明中？
也许建议我用 JWE 加密 JWT？如果是这种情况，如果我为每个请求解密，而不是进行数据库查找（我将使用 MongoDB 或 Redis），性能会不会降低更多，或者性能影响是否相同？
与我的 REST API 的连接将通过 HTTPS。
如果对第 3 方 API 的请求是通过您的服务器进行的，则将访问令牌存储在与用户绑定的数据库中，并使用存储为环境变量的密钥进行加密。如果数据库遭到破坏，则令牌是安全的。（奖励，使用生成并存储在移动应用程序上的密钥加密令牌。）
如果对第 3 方 API 的请求直接来自移动应用程序，请将访问令牌存储在手机上，并使用存储在服务器数据库中的每个用户的唯一密钥进行加密。敏感信息的分散存储比集中存储（分区）更安全。如果手机被盗，则需要先对您的服务器进行身份验证，然后才能获得解密密钥。如果您的服务器遭到入侵，则令牌不存在。
我没有用过智威汤逊。
访问令牌根据 RFC应该是有限访问。与其担心将高价值的东西存储在哪里，服务器可能会受到损害，不如简单地限制访问令牌的持续时间。
这在 RFC 中专门针对不记名令牌进行了说明：
发行短期不记名令牌：令牌服务器应该发行短期（一小时或更短）不记名令牌，特别是在向在 Web 浏览器或其他可能发生信息泄漏的环境中运行的客户端发行令牌时。使用短暂的不记名令牌可以减少它们被泄露的影响。