我应该在 OAuth 身份验证代码流程中重定向回 SPA 或 API 吗?

问题描述 投票:0回答:1

我有一个 React SPA 和一个 .NET API,用户将使用 AD FS 登录。我在后端用令牌交换身份验证代码(也使用客户端密钥),但将 cookie 发送回 SPA。流程是这样的:

  1. 用户打开 SPA,从 AD FS 重定向到登录页面 /oauth/authorize。生成代码验证器+状态。
  2. 用户登录并被重定向回前端。
  3. 前端检查 URL 中的身份验证码 + 状态,使用身份验证码 + 代码验证器验证并调用后端 /api/authenticate。
  4. 后端使用身份验证代码、代码验证程序和客户端密钥(仅存储在后端)调用 /oauth/token 端点,并返回令牌。将其放入内存中,但使用 cookie 使用户登录。
  5. SPA 使用 cookie 将所有请求发送到 API,浏览器中没有令牌。

这目前有效,但是,我不确定是否需要第 3 步,将用户重定向回前端,然后再次调用后端。

我不能在这里使用response_mode=form_post吗?这样,当用户在 AD 登录时,浏览器将身份验证代码发布到后端,后端将其交换为令牌,使用 cookie 使用户登录并重定向回前端?

这不是比在前端放置授权码更安全吗?

我在这里遗漏了一些东西还是这根本不可能?刚刚开始阅读 OAuth 和 OIDC。有时会感到困惑..

.net oauth-2.0 openid-connect single-page-application adfs
1个回答
0
投票

授权代码必须在浏览器响应中返回到前端通道。如果您查看表单帖子响应模式规范,您会发现它是来自浏览器的自动表单帖子,而不是后端到后端的帖子。所以使用form post并不会提高效率。

表单发布有助于防止在服务器日志或浏览器历史记录中泄露授权代码。表单发布还存在一个潜在的小可用性问题,如果用户在登录后点击后退按钮,可能会收到表单重新提交警告。

您可以使用您喜欢的任何响应模式。无论您使用哪个选项,目前建议同时使用 PKCE 和后端客户端凭据。这提供了很好的防御措施,以确保 HTTP 服务器或浏览器记录的任何代码都不会被利用。 JARM 规范中解释了一些更高的安全选项,一些授权服务器支持该规范。

© www.soinside.com 2019 - 2024. All rights reserved.