2

设想

  • 带有 IdentityServerAuthentication 的 ASP.NET Core MVC (API)，带有oidc-client-js 的Angular 2 。IdentityServer4，带有 ASP.NET Core Identity，作为 OP。使用红隼
  • nginx 反向代理 - SSL 终止，基本身份验证
  • oidc 隐式流

认证流程如下：

  1. 浏览器导航到应用程序
  2. 浏览器中的基本身份验证
  3. Angular 路由保护通知（通过 oidc-client）用户未登录（或 401 被捕获）
  4. 应用导航到unauthorized路线
  5. 用户点击sign in按钮，触发 UserManager (oidc-client)signinRedirect
  6. 浏览器被重定向到 OP (IdentityServer4)
  7. 用户在 OP 登录
  8. 重定向到应用登录回调 - 即 UserManagersigninRedirectCallback
  9. 基本身份验证弹出窗口 - 因为 oidc-client 调用connect/userinfo带有承载授权标头。

问题

用户现在停留在第 9 步。调用永远不会使用基本身份验证标头（或者更确切地说：两个标头组合）。用户只能取消，然后对 userinfo 端点的请求产生 401，让他们在应用程序中退出。

重复尝试将跳过第 5 步，因为在 OP 处登录的会话 cookie 仍然存在。

我不完全确定浏览器如何处理基本身份验证，尤其是在从 js/angular 发出的请求上。这可能是一个错误oidc-client-js吗？

我猜想我们的应用程序经过身份验证的 HTTP 请求必须检查是否已经存在授权并向其中添加不记名令牌（逗号分隔的授权标头，但只有一个这样的标头）。如果还没有发送 Authorization 标头，我们已经将 Authorization 标头附加到不记名令牌 - 但我无法真正尝试这一点，因为这种情况甚至没有进行到足以进行此类 api 调用的程度。

未设置基本身份验证时一切正常

我在开发过程中使用本地 nginx 来测试 HTTPS 重定向、SSL 终止检测 - 以及添加基本身份验证时的行为。

没有基本身份验证一切正常。X-Forwarded-For并且X-Forwarded-Proto标头被正确解释，HTTP 被重定向到 HTTPS 等。

为什么您甚至需要基本身份验证？

我们不希望公开提供该应用程序。最近添加了基于 OIDC 的身份验证，以及强制执行 HTTPS 等（应用程序尚未投入生产）

4

0 回答 0