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端点并接收accessTokenrefreshToken
  5. BE 返回accessTokenFE 并设置refreshTokenhttpOnlycookie(这个不确定,我可能会存储在 Redis 缓存中)。

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

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

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

  • /Login- 得到AccessTokenRefreshToken
  • /Refresh-AccessToken使用更新RefreshTokenaccessToken临近到期时,FE 会手动调用。

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

此外,据我所知,存储refreshTokenhttpOnlycookie 中是很常见的,该 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 回答