Asp.Net Core API OpenId-Connect 身份验证与 JWT 令牌使用 IdentityModel

Question

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

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

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

然后，FE 会在每个请求中添加Bearer AccessToken 进行身份验证。当AccessToken即将到期时，将使用refreshToken进行更新。

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

所以，现在我正在考虑使用我的自定义 BE 端点并使用 IdentityModel helper methods，但不确定这样处理身份验证是否是一个好习惯。

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

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

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

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

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

Answer 1

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

推荐方式

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

• Token Handler Blog Post
• Code Example
• Code Example Doc

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

存储刷新令牌

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