是否有基于 OIDC 的基于 IDaaS 的社交登录的标准模式？

Posted 2023-03-09

【中文标题】是否有基于 OIDC 的基于 IDaaS 的社交登录的标准模式？

【英文标题】：Is there a standard pattern for OIDC based Social Login with IDaaS?

【发布时间】：2019-04-11 14:43:22

【问题描述】：

场景：基于 openid-connect 的 SPA 社交登录。

案例 1： 如果 SPA 已注册为具有社交身份验证提供程序（例如 Google）的 OAuth 2.0 客户端，则 OAuth/OIDC 角色映射如下：

资源所有者 = 验证用户 客户 = SPA 授权服务器 = 社交身份验证提供商（例如 Google） 资源服务器 = 社交身份验证提供程序（例如 Google）

案例 2： 现在，让我们考虑使用 IDaaS（例如 Okta/Auth0）的 SPA 的社交身份验证的情况。 IDaaS 已向 Social Authentication Provider（例如 Google）注册了 OAuth 2.0 客户端，SPA 已向 IDaaS 注册了 OAuth 2.0 客户端。

问题：这个用例是否是两个 OIDC 流的组合（嵌套？）

流程一：

资源所有者 = 验证用户 客户端 = IDaaS（例如 Okta） 授权服务器 = 社交身份验证提供商（例如 Google） 资源服务器 = 社交身份验证提供程序（例如 Google）

（此时，Social Provider 已将 id_token (iss=Google, aud=IDaaS) 声明为 IDaaS redirect_uri）

流程2：

资源所有者 = 验证用户 客户 = SPA 授权服务器 IDaaS（例如 Okta） 资源服务器：IDaaS（例如 Okta）

（最后，IDaaS 已将 id_token (iss=IDaaS, aud=SPA) 断言到 SPA redirect_uri，此时对 SPA 的身份验证已完成）。

以上理解正确吗？

此外，对于这种涉及使用 IDaaS 作为身份代理的架构，是否有标准的 OIDC/OAuth 模式？

【参考方案1】：

您正在使用一个名为 OAuth 2.0/OpenID Connect federation 的概念。身份提供者供应商不是一个标准，而是使用这种集成的外部身份提供者。

案例 1 纯粹使用 OAuth 2.0 和 OpenID 连接。 SPA 只是依靠授权服务器来颁发令牌。

在案例 2 中，您依赖外部身份提供者（例如：- 如您的解释中的 Google）进行用户身份验证。如果您比较您的配置，您就是在将 IDaaS 配置为 Google 的客户端。然后您的 SPA 成为 IDaaS 的客户。

这个用例是两个 OIDC 流的组合吗？

不，它使用相同的 OIDC 流程。但不是 SPA 直接联系 Google，而是 IDaaS 发出请求（而不是转发请求）。 IDaaS 将创建授权请求并将 SPA 定向到 Google 的登录页面。这是通过 IDaaS 获取注册详细信息（例如重定向 URL、客户端 ID 和客户端密码）来完成的。

作为客户端，您将获得登录页面并提供凭据。完成后，OAuth 2.0/OpenID Connect 重定向将发生在 IDaaS（注意 - 在 Google，我们将重定向 URL 配置为 IDaaS）。 IDaaS 将接收重定向并对其进行处理。根据使用的流程，该步骤将涉及令牌请求。然后进行令牌处理。

在这一步中，IDaaS 将在内部替换令牌。它将首先验证 Google 颁发的令牌。如果令牌有效，IDaaS 将创建一个新令牌，其中包含 Google 要求的声明以及设置为 SPA 已知值的受众和颁发者值。

基本上 IDaaS 接收原始的 Google 令牌。 SPA 接收 IDaaS 创建的令牌。这是相同的流程，但中间的 IDaaS 与外部身份提供者一起工作。