4

我有一个 ASP.NET Core API 作为 Angular SPA 前端的后端。我使用Cognito作为身份提供者，并希望使用它创建一个 OpenId-Connect 身份验证authorization code flow，这意味着所有秘密凭据都将存储在后端。

授权流程应该是这样的（标准 OpenID Connect 流程）：

  1. FE 应用程序调用/authorize端点并被重定向到Cognito托管 UI。
  2. 输入凭证后，FE 会收到一个授权码。
  3. FE 使用授权码调用 BE。
  4. BE 调用/token端点并接收accessToken和refreshToken。
  5. BE 返回accessTokenFE 并设置refreshToken为httpOnlycookie（这个不确定，我可能会存储在 Redis 缓存中）。

然后，每个请求都会添加 FEBearer AccessToken进行身份验证。当AccessToken接近到期时，它将使用refreshToken.

我正在试验这个例子，但这里的应用程序使用 Asp.Net Core cookie 进行身份验证并忽略accessToken了refreshToken. 即使在accessToken过期后我也通过了身份验证。此外，没有太多关于 ASP.NET cookie 如何工作的文档。

因此，现在我正在考虑使用自定义 BE 端点并使用IdentityModel 辅助方法，但不确定处理这样的身份验证是否是一种好习惯。

  • /Login- 得到AccessToken和RefreshToken
  • /Refresh-AccessToken使用更新RefreshToken。accessToken临近到期时，FE 会手动调用。

那么，是否有一种“推荐”的方式来很好地处理这种情况而IdentityModel无需编写自定义实现？

此外，据我所知，存储refreshToken在httpOnlycookie 中是很常见的，该 cookie 将添加到发送到 BE 的每个请求中，但是accessToken当我已经refreshToken添加每个请求时，我看不出有什么意义。

refreshToken出于性能和安全原因，存储在 BE 中不是更好吗？

身份验证是每个应用程序的一部分，所以我相信也应该有一些内置的框架功能authorization code flow。

4

1 回答 1

1

您正在描述一种Backend for Frontend方法，这是一种很好的架构。确保将处理 OAuth 的专业 API 与一般业务 API 分开。

推荐方式

Curity 有一种方法可以为 SPA 提供最先进的安全性，这里有一些链接：

我们可能会在某个时候添加一个 .Net 令牌处理程序，但使用什么技术并不重要，因为这个想法是让专业 API 成为您插入的东西，而不是代码。

存储刷新令牌

我个人对 SPA 的偏好是使用 AES256 加密的仅 HTTP cookie。这非常符合避免在应用程序中使用 OAuth 管道的目标，并使令牌处理程序成为无状态的并且更易于部署和管理。

于 2021-11-30T19:49:39.180 回答