在OIDC

Question

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

我清楚地知道有关各方以及如何建立信任。

1. 对于我们需要与之集成的每个客户，首先获取IDP ID，数字证书等配置详细信息，并从我的Web应用程序端共享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看起来应该首先调用Authorization Server来获取访问令牌，然后使用此访问令牌在Resource Server上调用userInfo API。然后它看起来像上面的第2点，我的服务器是资源服务器是错误的。客户的IDP也应该是授权服务器和资源服务器？

在那种情况下，我的服务器在哪里适合整个OIDC流程？

Okta（客户的IDP）与我的服务器之间如何建立信任？

是否有可能在OIDC中实现与IDP启动的Fed SSO流（使用SAML）相当的流量？

Answer 1

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