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