我一直在尝试为Next.js项目实现可靠的身份验证流程，但现在我完全迷失了。我已经看过Next.js的示例存储库。但是对于完整的解决方案，我还有很多问题。
我有一个express.js API和一个单独的Next.js前端项目。所有数据和身份验证均由API处理。前端仅使用SSR呈现页面。如果我只创建一个整体项目，其中渲染页面和所有数据都由一台服务器处理（我的意思是使用Next.js的自定义服务器选项），那么我将只使用express-session和csurf。这将是管理会话并针对CSRF创建安全性的传统方式。
Express.js API不是必需的。这只是一个例子。它可以是Django API或.Net Core API。要点是，它是一个单独的服务器和一个单独的项目。
我如何拥有一个简单但可靠的结构？我检查了一些我最喜欢的网站（netlify，zeit.co，heroku，spectrum.chat等）。其中一些使用本地存储来存储访问和刷新令牌（易受XSS攻击）。其中一些使用cookie，甚至不使用HTTPOnly（XSS和CSRF都容易受到攻击）。还有诸如Spectrum.chat之类的示例使用了我上面提到的方式（cookie会话+防止csrf）。
我知道JWT令牌周围有巨大的炒作。但是我发现它们太复杂了。大多数教程只是跳过所有过期，令牌刷新，令牌吊销，黑名单，白名单等。
而且，Next.js的许多会话Cookie示例几乎从未提及CSRF。老实说，身份验证始终是我的大问题。有一天，我读到应该使用HTTPOnly cookie，第二天，我看到一个巨大的流行站点甚至没有使用它们。或者他们说“永远不要将令牌存储到localStorage”，而繁荣一些大型项目就只是使用这种方法。
有人能告诉我这种情况的方向吗？
我在当前的项目中也必须考虑这一点。我使用相同的技术：ExpressJS API和NextJS服务器端渲染的前端。
我选择做的是在ExpressJS API中使用passport.js。 YouTube上的TheNetNinja拥有21集的播放列表，非常好。他向您展示了如何在您的API中实现Google OAuth 2.0，但是这种逻辑会转移到任何其他策略（JWT，电子邮件+密码，Facebook身份验证等）。
在前端，我会从字面上将用户重定向到Express API中的网址。该网址将向用户显示Google OAuth屏幕，用户单击“允许”，API会做更多的工作，为特定用户制作Cookie，然后重定向回前端的网址。现在，用户已通过身份验证。
关于HTTPOnly cookie：我选择关闭此功能，因为我将信息存储在前端所需的cookie中。如果启用了此功能，则前端（javascript）无法访问这些cookie，因为它们是HTTPOnly。
以下是我正在谈论的播放列表的链接：https://www.youtube.com/watch?v=sakQbeRjgwg&list=PL4cUxeGkcC9jdm7QX143aMLAqyM-jTZ2x
希望我给了您指导方针。
编辑：我尚未回答您有关CSURF的问题，但这是因为我不熟悉它。