【发布时间】:2018-11-05 18:50:42
【问题描述】:
假设我们有一个 SPA,它依赖于我的应用程序中的 API。 SPA 和 REST API 都托管在同一台服务器上。现在我正在使用基于 SAML 的 IDP 发起的联合 SSO。
我清楚地知道所涉及的各方以及如何建立信任。
- 对于我们需要集成的每个客户,首先从我的 Web 应用程序端获取 IDP ID、数字证书等配置详细信息并共享 SAML ACS URL 等详细信息。
- 在客户端,他们使用我们提供的 SAML ACS URL 将我的应用程序添加为依赖方。
- 用户在 IDP 进行身份验证,然后将 SAMLResponse 发布到我的 ACS URL。
- 我们可以验证此 SAMLResponse 并观察 NameID 以识别用户并继续授予对我服务器上 API 的访问权限。
现在,假设客户端的 IDP 是像 Okta 这样的符合 OIDC 的服务,我是否可以通过在我的服务器端进行一些更改来实现类似的身份验证流程。看起来应该是可能的,但我无法将全貌拼凑在一起。
根据我对 OIDC 的理解,它看起来像
- SPA 是客户
- 我的暴露 REST API 的服务器是资源服务器。
- 客户的 IDP(Okta) 是授权服务器。
从我读过的文章看来,SPA 应该首先调用授权服务器以获取访问令牌,然后使用此访问令牌调用资源服务器上的 userInfo API。然后看起来上面的第 2 点我的服务器是资源服务器是错误的。客户的 IDP 也应该是授权服务器和资源服务器?
在这种情况下,我的服务器在整个 OIDC 流程中适合什么位置?
Okta(客户的 IDP)和我的服务器之间的信任是如何建立的?
是否可以在 OIDC 中实现与 IDP 发起的 Fed SSO 流(使用 SAML)等效的流?
【问题讨论】:
标签: oauth-2.0 saml okta openid-connect