什么是等效的 OpenID Connect 和 SAML 参与者/角色？答案

【问题标题】：What are the equivalent OpenID Connect and SAML actors/roles?什么是等效的 OpenID Connect 和 SAML 参与者/角色？
【发布时间】：2015-07-15 23:38:27
【问题描述】：

我无法理解 OpenID Connect 参与者/角色。我来自使用 SAML。在我熟悉的场景中，Service Provider 是一个具有受保护资源的 Web 应用程序，而 Identity Provider 服务器是用户进行身份验证的地方。对于 SAML，典型的客户端是 Web 浏览器，尽管 SAML 也有 ECP 配置文件，可以在其中使用非浏览器客户端（例如本机应用程序）。我了解所有这些部分的工作原理以及它们的各种流程。

我正在尝试将同样的理解应用到 OpenID Connect。我的理解是 OpenID Provider 和 Identity Provider 是一样的。但是其他部分呢？服务提供商是依赖方吗？那客户是什么？ OpenID Connect 文档将“依赖方”替换为“客户端”，这让我很反感。

对我来说，来自 SAML 的客户端要么是 Web 浏览器，要么是 ECP 的本地或移动应用程序。那么这种客户端在 OpenID Connect 世界中的作用是什么？

由于 OpenID Connect 是基于 OAuth 构建的，我已经熟悉了它，但这并没有消除这个 SAML 与 OpenID Connect 的混淆。任何帮助将不胜感激。谢谢！

【问题讨论】：

标签： single-sign-on saml openid-connect

【解决方案1】：

术语“客户端”是从 OAuth 2.0 继承的通用名称，用于请求、接收和使用令牌的实体。 OpenID Connect 建立在此之上，但由于现在有一个身份令牌在起作用，因此客户端也称为依赖方。

依赖方（或客户端）实际上与 SAML 服务提供者和 ECP 相同，是依赖 IDP 为其提供用户身份的实体。

依赖方（或客户端）可以是 Web 应用程序、本机应用程序或移动应用程序中的任何一个。

【讨论】：

我想我跟着你，但我想确定一下。 “依赖方”一词既包括 SAML 服务提供者又包括 ECP？假设服务提供者有一个 REST API，而 ECP 是一个需要访问该 API 的本机应用程序。在 OpenID Connect 中，Service Provider 和 ECP 都被视为“依赖方”？
很难，因为在某种意义上，原生应用程序和 REST API 被认为是同一方，因此它们确实可以是同一依赖方；但在某些情况下，本机应用程序和 API 都会获得单独的身份令牌，这使它们成为 2 个依赖方；归根结底，依赖方是消耗身份令牌的一方......