英文:
Acceptable OAuth Flow for a decoupled frontend/Backend Architecture?
问题
我有一个使用NextJS前端和Golang后端架构的应用，使用JWT进行身份验证，并且有一个内部的用户/密码数据库。我正在将OAuth登录添加到JWT系统中，但所有的API调用仍将继续使用JWT。我有一个工作原型，使用以下OAuth流程：
- 用户被引导到一个NextJS页面，显示各种登录选项按钮。
- 当选择一个提供者时，用户被重定向到后端的/auth/provider，然后再被重定向到提供者，带有所有必需的密钥和回调链接。
- 用户在提供者处登录，触发重定向到/auth/provider/callback。
- 后端服务器从回调中检索用户数据，并将用户电子邮件与内部用户数据连接起来以生成JWT。
- 后端返回一个页面，将JWT存储在本地存储中，并重定向到一个NextJS页面。
- NextJS页面可以使用存储的JWT进行API调用。
- 另一个步骤可以是，如果JWT被使用两次（可能是XSS攻击），则交换JWT以获得新的非存储JWT或会话cookie，并使新的JWT失效。
上述方法可以工作，但需要本地存储的JWT。这是否是一个问题，是否可能在不需要本地存储的JWT的情况下完成最后的步骤？
这个流程是否合理，还是我做错了？是否切换到PKCE会过度复杂？
对于当前的原型，我正在使用github.com/markbates/goth的示例代码作为Golang后端，以及一个基本的NEXTjs服务器。
英文:
I have a NextJS frontend and Golang backend architecture with an authentication system using JWTs and an internal user/password database. I'm adding OAuth sign-in in addition to the JWT system, but all API calls will still be maintained using JWTs. I have a working prototype that uses the following OAuth flow:
- User is directed to a NextJS page that displays various login options as buttons.
- When a provider is chosen, the user is redirected to the backend at /auth/provider where they are then redirected to the provider with all required keys and callback links.
- User logs in at the provider and the redirect is triggered to /auth/provider/callback.
- The backend server retrieves the user data from the callback and connects the user email to the internal user data for generating a JWT.
- The backend returns a page that stores the JWT in local storage and redirects to a NextJS page.
- The NextJS page can then use the stored JWT to make API calls.
- An additional step could be to exchange the JWT for a new, non-stored JWT or session cookie if the JWT is used twice (potential XSS attempt) and the new JWT is invalidated.
The above method works, but requires a locally stored JWT. Is this a concern, and is it possible to complete the final steps without the need for a locally stored JWT.
Does this flow make sense or am i going about it all wrong? Would swapping to PKCE be overkill?
For the current prototype I'm using the github.com/markbates/goth example code running as the golang backend and a basic NEXTjs server
答案1
得分: 1
实际上，你在那里有一种前端后端的形式。值得浏览一下面向浏览器应用的OAuth，这与上述文档的第6.2节有些相似。
一种选择是将后端托管在类似https://api.example.com这样的URL上，然后让它为托管在类似https://www.example.com这样的URL上的Next.js应用程序编写cookie。
通过这种方式，OAuth流程的后端和前端部分是解耦的，而且还避免了本地存储的JWT。请注意，为了使cookie被视为第一方cookie并避免被浏览器删除，需要满足相同的域名要求。
英文:
In effect you have a form of backend for frontend there. It is worth browsing OAuth for browser based apps a little similar to section 6.2 of the above doc.
One option might be to host the backend at a URL like https://api.example.com, then make it write cookies for the Next.js app, hosted at a URL like https://www.example.com.
In this way the backend and frontend parts of the OAuth flow are decoupled, and you also avoid locally stored JWTs. Note the same domain prerequisite, needed for the cookie to be considered first-party, and therefore avoid being dropped by browsers later.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论