【问题标题】:Achieving authentication flow similar to SAML in OIDC在 OIDC 中实现类似于 SAML 的身份验证流程
【发布时间】:2018-11-05 18:50:42
【问题描述】:

假设我们有一个 SPA,它依赖于我的应用程序中的 API。 SPA 和 REST API 都托管在同一台服务器上。现在我正在使用基于 SAML 的 IDP 发起的联合 SSO。

我清楚地知道所涉及的各方以及如何建立信任。

  1. 对于我们需要集成的每个客户,首先从我的 Web 应用程序端获取 IDP ID、数字证书等配置详细信息并共享 SAML ACS URL 等详细信息。
  2. 在客户端,他们使用我们提供的 SAML ACS URL 将我的应用程序添加为依赖方。
  3. 用户在 IDP 进行身份验证,然后将 SAMLResponse 发布到我的 ACS URL。
  4. 我们可以验证此 SAMLResponse 并观察 NameID 以识别用户并继续授予对我服务器上 API 的访问权限。

现在,假设客户端的 IDP 是像 Okta 这样的符合 OIDC 的服务,我是否可以通过在我的服务器端进行一些更改来实现类似的身份验证流程。看起来应该是可能的,但我无法将全貌拼凑在一起。

根据我对 OIDC 的理解,它看起来像

  1. SPA 是客户
  2. 我的暴露 REST API 的服务器是资源服务器。
  3. 客户的 IDP(Okta) 是授权服务器。

从我读过的文章看来,SPA 应该首先调用授权服务器以获取访问令牌,然后使用此访问令牌调用资源服务器上的 userInfo API。然后看起来上面的第 2 点我的服务器是资源服务器是错误的。客户的 IDP 也应该是授权服务器和资源服务器?

在这种情况下,我的服务器在整个 OIDC 流程中适合什么位置?

Okta(客户的 IDP)和我的服务器之间的信任是如何建立的?

是否可以在 OIDC 中实现与 IDP 发起的 Fed SSO 流(使用 SAML)等效的流?

【问题讨论】:

    标签: oauth-2.0 saml okta openid-connect


    【解决方案1】:

    您可以使用 Openid Connect 隐式授权类型(以及 response_mode=form_post)来实现类似 SAML HTTP Post 绑定的用户体验。如果您的 IdP 不支持 form_post,则令牌将作为片段返回并留在浏览器中,您将需要代码从浏览器获取令牌。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2020-03-09
      • 2020-03-03
      • 2021-02-17
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多