使用 SSO 断言（JWT 或 SAML）用于 OAuth 断言流程是否常见？
Is using a SSO Assertion (JWT or SAML) For OAuth Assertion Flow Common?
我正在处理一组公开使用 OAuth 2 进行身份验证的 REST API 的系统。这些系统中的各种都有自己独立的用户帐户集，所有用户标识符都没有通用的概念系统。
对于交互式使用，我们已经有了 SAML 单点登录解决方案，因此用户可以登录到身份提供者（知道他们在所有系统中的用户帐户）一次，然后使用 SAML 自动登录到每个系统.
我想将此模式扩展到我们的 OAuth 2 身份验证 API。 IE。允许用户使用他们的身份提供者凭据进行一次身份验证，然后能够针对每个系统触发 OAuth 2 身份验证流程以获取不记名令牌，而无需用户输入每组凭据。
我找到了 2 个可以让我实现这一目标的规范草案：
- SAML 2.0 Profile for OAuth 2.0 Client Authentication and AuthorizationGrants 这将允许我使用 SAML 请求启动 OAuth 身份验证流程
- JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants 这将允许我使用 JWT 而不是 SAML 来做同样的事情
但这些都是草稿，在投入过多之前，我想了解这些模式的使用是否相对广泛，或者我是否支持边缘案例技术。
所以我的问题是：
- 这些类型的 SSO 模式是否与 OAuth 2 通用？
- 是否有解决相同问题的常用替代方法？
这些草稿似乎是由 Salesforce.com 撰写并由他们使用：SAML, JWT。
我在这里也看到了一些关于它们用于 Salesforce.com 的问题，这表明它们至少实际被使用过。
我还看到一个未回答的问题，询问是否 Windows Azure supports this flow 这表明其他人至少也在寻找同样的问题。
似乎 google 将 JWT 变体用于使用“服务帐户”的服务器到服务器应用程序 Details Here
We 广泛使用 Salesforce 端点进行令牌交换，并完全按照您的意愿行事。其他系统在概念上相似，但实现略有不同，返回不同形式的 access_token（例如 SAP、AWS 是两个很好的例子）。
所有这些都遵循一个模型，在该模型中，它们是用于调用其 API 的安全工件的发布者。换句话说：
- 用户验证（到网站）。
- 有一些东西代表该身份验证（例如 SAML 令牌）
- 您调用特定的 API 以将用户工件交换为 API
access_token。
其他应用使用的另一种方法是为 API 做与他们为网站做的相同的事情：使用可以从可信实体[=32]生成的工件=] 以标准方式。 JWT 是一个很好的选择。后者由 Azure 移动服务、Firebase、Layer.com.
使用
在我们的实现中，我们默认选择了后一种模型，同时也对前者实现了对所有系统的抽象，简化了用户代码。我们称之为 "identity delegation" 端点，它的签名看起来像 this。 api_type 参数定义您要为哪种系统交换令牌（SAP、Salesforce、Layer 等）。
首先让我对您描述的问题进行观察。从本质上看，跨多个 OAuth 授权服务器的联合并没有真正作为一种商品得到解决。换句话说，每组受保护的资源都有自己的 OAS，您需要请求令牌。我 运行 了解这个问题和业务需求。
我假设发出身份断言的 IdP（例如 SAML、WS-Federation）与托管 OAuth 安全 API 的资源服务器不同。我使用的一种技术是返回到发布身份的服务器并利用 STS 交换 SAML Bearer 令牌的身份，并将 SAML Bearer 提供给已集成到您的资源的 OAuth 授权服务器 (OAS)正在尝试访问，然后为其安全 APIs 颁发访问令牌。当然，这仅在发出初始断言的 IdP 还提供 STS 以获取 SAML Bearer 令牌的情况下才有效。您在上面记录的 JWT 配置文件是行业内的思想领袖正在努力解决跨多个 OAuth 授权服务器的联合问题的地方。我还没有看到它在整个行业中的整合。
我正在处理一组公开使用 OAuth 2 进行身份验证的 REST API 的系统。这些系统中的各种都有自己独立的用户帐户集，所有用户标识符都没有通用的概念系统。
对于交互式使用，我们已经有了 SAML 单点登录解决方案，因此用户可以登录到身份提供者（知道他们在所有系统中的用户帐户）一次，然后使用 SAML 自动登录到每个系统.
我想将此模式扩展到我们的 OAuth 2 身份验证 API。 IE。允许用户使用他们的身份提供者凭据进行一次身份验证，然后能够针对每个系统触发 OAuth 2 身份验证流程以获取不记名令牌，而无需用户输入每组凭据。
我找到了 2 个可以让我实现这一目标的规范草案：
- SAML 2.0 Profile for OAuth 2.0 Client Authentication and AuthorizationGrants 这将允许我使用 SAML 请求启动 OAuth 身份验证流程
- JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants 这将允许我使用 JWT 而不是 SAML 来做同样的事情
但这些都是草稿，在投入过多之前，我想了解这些模式的使用是否相对广泛，或者我是否支持边缘案例技术。
所以我的问题是：
- 这些类型的 SSO 模式是否与 OAuth 2 通用？
- 是否有解决相同问题的常用替代方法？
这些草稿似乎是由 Salesforce.com 撰写并由他们使用：SAML, JWT。
我在这里也看到了一些关于它们用于 Salesforce.com 的问题，这表明它们至少实际被使用过。
我还看到一个未回答的问题，询问是否 Windows Azure supports this flow 这表明其他人至少也在寻找同样的问题。
似乎 google 将 JWT 变体用于使用“服务帐户”的服务器到服务器应用程序 Details Here
We 广泛使用 Salesforce 端点进行令牌交换，并完全按照您的意愿行事。其他系统在概念上相似，但实现略有不同，返回不同形式的 access_token（例如 SAP、AWS 是两个很好的例子）。
所有这些都遵循一个模型，在该模型中，它们是用于调用其 API 的安全工件的发布者。换句话说：
- 用户验证（到网站）。
- 有一些东西代表该身份验证（例如 SAML 令牌）
- 您调用特定的 API 以将用户工件交换为 API
access_token。
其他应用使用的另一种方法是为 API 做与他们为网站做的相同的事情：使用可以从可信实体[=32]生成的工件=] 以标准方式。 JWT 是一个很好的选择。后者由 Azure 移动服务、Firebase、Layer.com.
使用在我们的实现中，我们默认选择了后一种模型，同时也对前者实现了对所有系统的抽象，简化了用户代码。我们称之为 "identity delegation" 端点，它的签名看起来像 this。 api_type 参数定义您要为哪种系统交换令牌（SAP、Salesforce、Layer 等）。
首先让我对您描述的问题进行观察。从本质上看，跨多个 OAuth 授权服务器的联合并没有真正作为一种商品得到解决。换句话说，每组受保护的资源都有自己的 OAS，您需要请求令牌。我 运行 了解这个问题和业务需求。
我假设发出身份断言的 IdP（例如 SAML、WS-Federation）与托管 OAuth 安全 API 的资源服务器不同。我使用的一种技术是返回到发布身份的服务器并利用 STS 交换 SAML Bearer 令牌的身份，并将 SAML Bearer 提供给已集成到您的资源的 OAuth 授权服务器 (OAS)正在尝试访问，然后为其安全 APIs 颁发访问令牌。当然，这仅在发出初始断言的 IdP 还提供 STS 以获取 SAML Bearer 令牌的情况下才有效。您在上面记录的 JWT 配置文件是行业内的思想领袖正在努力解决跨多个 OAuth 授权服务器的联合问题的地方。我还没有看到它在整个行业中的整合。