我有一个ASP.NET Core API作为Angular SPA前端的后端。我使用Cognito作为身份提供程序，并希望使用authorization code flow创建OpenId Connect身份验证，这意味着所有机密凭据都将存储在后端。
授权流程应该是这样的(标准OpenID连接流程(：
- FE应用程序调用
/authorize端点并重定向到承载Cognito的UI - 在输入凭证之后，FE接收授权代码
- FE使用授权码调用BE
- BE调用
/token端点并接收accessToken和refreshToken - BE将
accessToken返回给FE，并将refreshToken设置为httpOnlycookie(对此不确定，我可能会将其存储在Redis缓存中(
然后，每个请求的FE都会添加Bearer AccessToken进行身份验证。当AccessToken接近到期时，它将使用refreshToken进行更新。
我尝试过这个例子，但这里的应用程序使用Asp.Net Core cookie进行身份验证，而忽略了accessToken和refreshToken。即使在accessToken过期之后，我也通过了身份验证。此外，没有太多关于ASP.NET cookie如何工作的文档。
因此，现在我正在考虑使用自定义BE端点并使用IdentityModel辅助方法，但不确定这样处理身份验证是否是一种好的做法。
/Login-获取AccessToken和RefreshToken/Refresh-使用RefreshToken更新AccessToken。FE将在accessToken即将到期时手动调用它
那么，是否存在"；推荐的"；如何在不编写自定义实现的情况下用IdentityModel很好地处理这种情况
此外，据我所知，将refreshToken存储在httpOnlycookie中是很常见的，它将被添加到发送给be的每个请求中，但当我已经在每个请求中添加了refreshToken时，我看不出有accessToken的意义。
出于性能和安全考虑，将refreshToken存储在BE内不是更好吗
身份验证是每个应用程序的一部分，所以我认为authorization code flow也应该有一些内置的框架功能。
您正在描述一种Backend for Frontend方法，这是一种很好的体系结构。请确保将处理OAuth的专家API与一般业务API分开。
推荐方式
Curity有一种为SPAs提供最先进安全的方法，以下是一些链接：
- 令牌处理程序博客文章
- 代码示例
- 代码示例文档
我们可能会在某个时候添加.Net令牌处理程序，但使用什么技术并不重要，因为我们的想法是让专业的API成为您插入的东西，而不是代码。
储存刷新代币
我个人对SPAs的偏好是使用AES256加密的HTTP专用cookie。这非常符合在应用程序中避免OAuth管道的目标，并使令牌处理程序成为无状态的，更易于部署和管理。