可接受的 OAuth 解耦前端/后端架构的流程？

Question

我有一个 NextJS 前端和 Golang 后端架构，以及一个使用 JWT 和内部用户/密码数据库的身份验证系统。 除了 JWT 系统之外，我还添加了 OAuth 登录，但所有 API 调用仍将使用 JWT 进行维护。 我有一个使用以下 OAuth 流程的工作原型：

1. 用户被定向到一个 NextJS 页面，该页面将各种登录选项显示为按钮。
2. 选择提供商后，用户将被重定向到位于 /auth/provider 的后端，然后他们将被重定向到具有所有必需密钥和回调链接的提供商。
3. 用户在提供商处登录，重定向被触发到 /auth/provider/callback。
4. 后端服务器从回调中检索用户数据并将用户 email 连接到内部用户数据以生成 JWT。
5. 后端返回一个页面，该页面将 JWT 存储在本地存储中，并重定向到 NextJS 页面。
6. 然后 NextJS 页面可以使用存储的 JWT 进行 API 调用。
7. 如果 JWT 被使用两次（潜在的 XSS 尝试）并且新的 JWT 无效，则可以将 JWT 交换为新的、未存储的 JWT 或 session cookie。

上述方法有效，但需要本地存储的 JWT。这是一个问题吗，是否可以在不需要本地存储的 JWT 的情况下完成最后的步骤。

这个流程有意义还是我做错了？ 换成 PKCE 会不会太过分了？

对于当前原型，我使用 github.com/markbates/goth 示例代码作为 golang 后端和基本 NEXTjs 服务器运行

Answer 1

实际上，您在那里有一种前端后端形式。 值得浏览OAuth 基于浏览器的应用程序。 一些最佳实践包括：

• 使用response_type=code ，以便在浏览器响应中不返回任何标记
• 按照OAuth 2.1中的建议使用 PKCE
• 在后端使用客户端密码

还建议添加一个应用程序 cookie 层，如第 7 步中所示。这样可以将令牌排除在浏览器之外，利益相关者通常会担心令牌拦截和渗漏威胁。 这个额外的层增加了复杂性。

好的第一步通常是与利益相关者（例如您公司的利益相关者）讨论浏览器安全要求，并让他们知道您提出的设计。 这有助于设定预期，例如，如果 cookie 工作有点昂贵。