场景：基于openid连接的SPA社交登录。
案例1:如果SPA已在社交身份验证提供商(如谷歌(注册为OAuth 2.0客户端，则OAuth/OIDC角色映射如下：
- 资源所有者=身份验证用户
- 客户=SPA
- 授权服务器=社交身份验证提供商(例如谷歌(
- 资源服务器=社交身份验证提供商(例如谷歌(
案例2:现在，让我们考虑使用IDaaS(例如Okta/Auth0(对SPA进行社会身份验证的案例。IDaaS已向社交身份验证提供商(如谷歌(注册了OAuth 2.0客户端，SPA已向IDaaS注册了OAauth 2.0客户端。
问题：这个用例是两个OIDC流(嵌套的？(的组合吗
流程1:
- 资源所有者=身份验证用户
- 客户=IDaaS(例如Okta(
- 授权服务器=社交身份验证提供商(例如谷歌(
- 资源服务器=社交身份验证提供商(例如谷歌(
(此时社交提供商已将id_token(iss=Google，aud=IDaaS(断言为IDaaS redirect_uri(
流程2:
- 资源所有者=身份验证用户
- 客户=SPA
- 授权服务器IDaaS(例如Okta(
- 资源服务器：IDaaS(例如Okta(
(最后，IDaaS已向SPA redirect_uri断言id_token(iss=IDaaS，aud=SPA(，此时已完成对SPA的身份验证(。
以上理解正确吗？
此外，对于这种涉及使用IDaaS作为身份代理的体系结构，是否有标准的OIDC/OAuth模式？
您使用的是一个名为OAuth 2.0/OpenID Connect联盟的概念。身份提供程序供应商使用这种集成外部身份提供程序，而不是作为标准。
案例1纯粹使用OAuth 2.0和OpenID连接。SPA只是依靠授权服务器来发布令牌。
在情况2中，您依赖外部身份提供商(如您的解释所示，例如：-Google(进行用户身份验证。如果你比较一下你的配置，你就是在把IDaaS配置成谷歌的客户端。然后你的SPA成为IDaaS的客户。
这个用例是两个OIDC流的组合吗
不，它使用相同的OIDC流。但是，与SPA直接联系谷歌不同，IDaaS提出了请求(而不是转发请求(。IDaaS将创建授权请求并将SPA引导到谷歌的登录页面。这是通过IDaaS获取注册的详细信息来完成的，如重定向URL、客户端id和客户端机密。
作为客户端，您可以获得登录页面并提供凭据。完成后，OAuth 2.0/OpenID Connect重定向到IDaaS(注意-在谷歌，我们将URL重定向到IDaaS(。IDaaS将接收重定向并对其进行处理。根据所使用的流，步骤中将涉及令牌请求。然后进行令牌处理。
在此步骤中，IDaaS将在内部替换令牌。它将首先验证谷歌发行的代币。如果令牌有效，IDaaS将创建一个新的令牌，其中包含谷歌要求的声明以及设置为SPA已知值的受众和发行者值。
基本上IDaaS接收原始的Google令牌。SPA接收IDaaS创建的令牌。它是相同的流，但是中间的IDaaS与外部身份提供者一起工作。