可以在加密的 JWT 中加密第 3 方访问令牌和刷新令牌吗？

Question

我有一个带有 React 前端和 FastAPI (python) 后端的全栈应用程序，它最终围绕用户使用 Spotify 进行身份验证并生成播放列表数据。

由于应用程序及其显示的数据专门链接到他们的Spotify帐户，我不想为我自己的应用程序/网站创建额外的帐户创建+登录过程（包括数据库维护），但我显然需要添加对我的应用程序进行一些身份验证。

这是我的想法：我使用 OAuth2.0 身份验证代码流模式对 Spotify 进行身份验证，该模式由我的后端（前端的后端模式）执行。因此，后端在身份验证后执行访问令牌交换...使用从 Spotify 收到的令牌，我可以通过类似 python-jose 之类的东西创建一个 ENCRYPTED JWT 令牌，它由用户的 Spotify OAuth 访问令牌组成和刷新令牌？然后在我的前端和后端之间来回传递 that，通过每个请求验证后端上的 JWT 令牌，并解密有效负载以接收用户的访问/刷新令牌。然后我可以使用它们来查询 Spotify API 并将预期的 Spotify 用户数据返回到我的前端。

这是一个安全的解决方案吗？

Answer 1

与直接在浏览器中使用 Spotify 令牌相比，加密 JWT 并不会增加任何安全性，因为攻击者只需要发送加密的 JWT 即可获取数据。

更好的解决方案是让您最好的朋友限制恶意 JavaScript 的影响。这将涉及您的 BFF 发布加密的 cookie，而不是加密的 JWT。恶意 JS 无法访问和泄露 HttpOnly cookie，但它可能能够泄露加密的 JWT。

您可能会发出一个 AT cookie 和一个 RT cookie，具有这些属性。使用对称算法（如 AES256-GCM）加密 cookie。

• 仅限 Http
• 同站点=严格
• 安全
• AT cookie 的路径=/ 或 RT cookie 的 /refresh

您的端到端流程基本上按照您的建议运行。该解决方案还遵循基于浏览器的应用程序的主流最佳实践。恶意 JS 可能仍然会滥用 cookie 并窃取数据，但当用户离开页面等时，此类攻击就会结束。